exec - Invoca subprocessos
Sinopse
exec? comuta ? arg ? arg … ?
Descrição
Esse comando trata seus argumentos como a especificação de um ou mais subprocessos a serem executados. Os argumentos assumem a forma de um pipeline de shell padrão, onde cada arg torna-se uma palavra de um comando e cada comando distinto se torna um subprocesso.
Se os argumentos iniciais paraexec começar com- então eles são tratados como opções de linha de comando e não fazem parte da especificação do pipeline. Os seguintes switches são atualmente suportados:
-keepnewline
Mantém uma nova linha à direita na saída do pipeline. Normalmente, uma nova linha final será excluída.
--
Marca o final dos switches. O argumento após este será tratado como o primeiro arg mesmo que comece com um-.
Se um arg (ou par de arg 's) tem uma das formas descritas abaixo, então é usado porexec para controlar o fluxo de entrada e saída entre os subprocessos. Tais argumentos não serão passados para o (s) subprocesso (s). Em formas como `` < nome do arquivo '' nome do arquivo pode estar em um argumento separado de `` <'' ou no mesmo argumento sem espaço intermediário (ou seja, `` < nome do arquivo '').
|
Separa os comandos distintos no pipeline. A saída padrão do comando anterior será canalizada para a entrada padrão do próximo comando.
|&
Separa os comandos distintos no pipeline. Tanto a saída padrão quanto o erro padrão do comando anterior serão canalizados para a entrada padrão do próximo comando. Essa forma de redirecionamento substitui formulários como 2> e> &.
< nome do arquivo
O arquivo nomeado por nome do arquivo é aberto e usado como entrada padrão para o primeiro comando no pipeline.
<@ fileId
FileId deve ser o identificador de um arquivo aberto, como o valor de retorno de uma chamada anterior paraabrir. É usado como entrada padrão para o primeiro comando no pipeline. FileId deve ter sido aberto para leitura.
<< valor
Valor é passado para o primeiro comando como sua entrada padrão.
> nome do arquivo
A saída padrão do último comando é redirecionada para o arquivo nomeado nome do arquivo , sobrescrevendo seu conteúdo anterior.
2> nome do arquivo
Erro padrão de todos os comandos no pipeline é redirecionado para o arquivo nomeado nome do arquivo , sobrescrevendo seu conteúdo anterior.
>& nome do arquivo
Tanto a saída padrão do último comando quanto o erro padrão de todos os comandos são redirecionados para o arquivo nomeado nome do arquivo , sobrescrevendo seu conteúdo anterior.
>> nome do arquivo
A saída padrão do último comando é redirecionada para o arquivo nomeado nome do arquivo , anexando a ela em vez de sobrescrevê-la.
2>> nome do arquivo
Erro padrão de todos os comandos no pipeline é redirecionado para o arquivo nomeado nome do arquivo , anexando a ela em vez de sobrescrevê-la.
>>& nome do arquivo
Tanto a saída padrão do último comando quanto o erro padrão de todos os comandos são redirecionados para o arquivo nomeado nome do arquivo , anexando a ela em vez de sobrescrevê-la.
>@ fileId
FileId deve ser o identificador de um arquivo aberto, como o valor de retorno de uma chamada anterior paraabrir. A saída padrão do último comando é redirecionada para fileId 's arquivo, que deve ter sido aberto por escrito.
2>@ fileId
FileId deve ser o identificador de um arquivo aberto, como o valor de retorno de uma chamada anterior paraabrir. Erro padrão de todos os comandos no pipeline é redirecionado para fileId arquivo. O arquivo deve ter sido aberto para gravação.
>&@ fileId
FileId deve ser o identificador de um arquivo aberto, como o valor de retorno de uma chamada anterior paraabrir. Tanto a saída padrão do último comando como o erro padrão de todos os comandos são redirecionados para fileId arquivo. O arquivo deve ter sido aberto para gravação.
Se a saída padrão não tiver sido redirecionada, oexec comando retorna a saída padrão do último comando no pipeline. Se algum dos comandos no pipeline sair anormalmente ou for morto ou suspenso,exec retornará um erro e a mensagem de erro incluirá a saída do pipeline seguida de mensagens de erro descrevendo as terminações anormais; aErro de código variável conterá informações adicionais sobre a última terminação anormal encontrada. Se algum dos comandos gravar em seu arquivo de erro padrão e esse erro padrão não for redirecionado,exec retornará um erro; a mensagem de erro incluirá a saída padrão do pipeline, seguida por mensagens sobre terminações anormais (se houver), seguidas pela saída de erro padrão.
Se o último caractere do resultado ou mensagem de erro for uma nova linha, esse caractere será normalmente excluído do resultado ou da mensagem de erro. Isso é consistente com outros valores de retorno do Tcl, que normalmente não terminam com novas linhas. No entanto, se-keepnewline é especificado, então a nova linha final é retida.
Se a entrada padrão não for redirecionada com `` <'' ou `` << '' ou `` <@ '', a entrada padrão para o primeiro comando no pipeline é obtida da entrada padrão atual do aplicativo.
Se o último arg é `` & '', então o pipeline será executado em segundo plano. Neste caso, oexeccomando retornará uma lista cujos elementos são os identificadores de processo para todos os subprocessos no pipeline.A saída padrão do último comando no pipeline irá para a saída padrão do aplicativo se não tiver sido redirecionada, e a saída de erro de todos os comandos no pipeline irá para o arquivo de erro padrão do aplicativo, a menos que seja redirecionada.
A primeira palavra em cada comando é tomada como o nome do comando; A substituição de til é executada e, se o resultado não contiver barras, os diretórios na variável de ambiente PATH serão procurados por um executável pelo nome fornecido. Se o nome contiver uma barra, deverá referir-se a um executável acessível a partir do diretório atual. Nenhuma expansão `` glob '' ou outras substituições semelhantes a shell são executadas nos argumentos para comandos.
Problemas de portabilidade
janelas (Todas versões)
Lendo ou escrevendo para um socket, usando o ``@ fileId '' notação, não funciona. Ao ler de um soquete, um aplicativo DOS de 16 bits será interrompido e um aplicativo de 32 bits retornará imediatamente com o final de arquivo. Quando qualquer tipo de aplicativo grava em um soquete, as informações são enviadas para o console, se houver uma presente, ou são descartadas.
O widget de texto do console Tk não fornece recursos IO padrão reais. Em Tk, ao redirecionar da entrada padrão, todos os aplicativos verão um fim de arquivo imediato; informações redirecionadas para saída padrão ou erro padrão serão descartadas.
As barras de avanço ou retrocesso são aceitas como separadores de caminho para argumentos para comandos Tcl. Ao executar um aplicativo, o nome do caminho especificado para o aplicativo também pode conter barras de avanço ou retrocesso como separadores de caminho. Lembre-se, no entanto, que a maioria dos aplicativos do Windows aceita argumentos com barras apenas como delimitadores de opção e barras invertidas somente em caminhos. Quaisquer argumentos para um aplicativo que especifique um nome de caminho com barras não serão convertidos automaticamente para usar o caractere de barra invertida. Se um argumento contiver barras como o separador de caminho, ele poderá ou não ser reconhecido como um nome de caminho, dependendo do programa.
Além disso, ao chamar um aplicativo DOS ou Windows 3.X de 16 bits, todos os nomes de caminho devem usar o formato de caminho curto e enigmático (por exemplo, usando `` applba ~ 1.def '' em vez de `` applbakery.default '' ).
Duas ou mais barras de avanço ou retrocesso em uma linha em um caminho referem-se a um caminho de rede. Por exemplo, uma simples concatenação do diretório raizc: / com um subdiretório/ windows / system vai renderc: // windows / system (duas barras juntas), que se refere ao ponto de montagem chamadosistema na máquina chamadajanelas (e ac: / é ignorado) e não é equivalente ac: / windows / system, que descreve um diretório no computador atual. ojunção de arquivos comando deve ser usado para concatenar os componentes do caminho.
Windows NT
Ao tentar executar um aplicativo,exec primeiro procura o nome como foi especificado. Então, em ordem.com, .Exee.bastão são acrescentados ao final do nome especificado e ele procura o nome mais longo. Se um nome de diretório não foi especificado como parte do nome do aplicativo, os seguintes diretórios serão pesquisados automaticamente em ordem ao tentar localizar o aplicativo:
O diretório do qual o executável do Tcl foi carregado.O diretório atual.O diretório do sistema Windows NT de 32 bits.O diretório do sistema Windows NT de 16 bits.O diretório inicial do Windows NT.Os diretórios listados no caminho. A fim executar os comandos internos do escudo comodir ecópia de, o chamador deve preceder ``cmd.exe / c'' para o comando desejado. Windows 95 Ao tentar executar um aplicativo,exec primeiro procura o nome como foi especificado. Então, em ordem.com, .Exee.bastão são acrescentados ao final do nome especificado e ele procura o nome mais longo. Se um nome de diretório não foi especificado como parte do nome do aplicativo, os seguintes diretórios serão pesquisados automaticamente em ordem ao tentar localizar o aplicativo: O diretório do qual o executável do Tcl foi carregado.O diretório atual.O diretório do sistema Windows 95.O diretório inicial do Windows 95.Os diretórios listados no caminho. A fim executar os comandos internos do escudo comodir ecópia de, o chamador deve preceder ``command.com / c'' para o comando desejado. Depois que um aplicativo DOS de 16 bits ler a entrada padrão de um console e, em seguida, sair, todos os aplicativos DOS de 16 bits executados posteriormente verão a entrada padrão como já fechada. Aplicativos de 32 bits não têm esse problema e serão executados corretamente, mesmo depois que um aplicativo DOS de 16 bits acha que a entrada padrão está fechada. Não há solução conhecida para esse bug no momento. Redirecionamento entre oNUL: dispositivo e um aplicativo de 16 bits nem sempre funciona. Ao redirecionar deNUL:alguns aplicativos podem travar, outros receberão um fluxo infinito de bytes "0x01", e alguns obterão um fim de arquivo imediato; o comportamento parece depender de algo compilado no próprio aplicativo. Ao redirecionar mais de 4K ou mais paraNUL:, alguns aplicativos serão interrompidos. Os problemas acima não ocorrem com aplicativos de 32 bits. Todos os aplicativos de 16 bits do DOS são executados de forma síncrona. Todas as entradas padrão de um pipe para um aplicativo DOS de 16 bits são coletadas em um arquivo temporário; a outra extremidade do pipe deve ser fechada antes que o aplicativo DOS de 16 bits comece a ser executado.Toda saída padrão ou erro de um aplicativo DOS de 16 bits para um pipe é coletada em arquivos temporários; o aplicativo deve terminar antes que os arquivos temporários sejam redirecionados para o próximo estágio do pipeline. Isso ocorre devido a uma solução alternativa para um bug do Windows 95 na implementação de pipes e é como o shell padrão do Windows 95 DOS manipula os próprios pipes. Certas aplicações, comocommand.com, não deve ser executado de forma interativa. Os aplicativos que acessam diretamente a janela do console, em vez de ler a entrada padrão e a gravação na saída padrão, podem falhar, travar o Tcl ou até travar o sistema se a janela do console privado não estiver disponível para eles. Macintosh oexec comando não está implementado e não existe no Macintosh. Unix oexec O comando é totalmente funcional e funciona conforme descrito. erro (n), aberto (n) executar, pipeline, redirecionamento, subprocesso Importante: Use o homem comando ( % homem ) para ver como um comando é usado em seu computador particular. Veja também
Palavras-chave
