exec - Invocar subproceso (es)
Sinopse
exec ? interruptores ? arg ? arg ... ?
Descrición
Este comando trata os seus argumentos como a especificación dun ou máis subprocesos para executar. Os argumentos toman a forma dun gasoduto estándar onde cada arg converteuse nunha palabra dun comando, e cada comando distinto convértese nun subproceso.
Se os argumentos iniciais para executar comezan con - entón son tratados como conmutadores de liña de comandos e non forman parte da especificación do gasoduto. Os seguintes switches son actualmente compatibles:
-keepnewline
Mantén unha nova liña final na saída da tubería. Normalmente eliminarase unha nova liña final.
-
Marque o final dos interruptores. O argumento que segue este será tratado como o primeiro arg aínda que comece con a - .
Se un argumento (ou un par de argumentos ) ten un dos formularios descritos a continuación, é usado por exec para controlar o fluxo de entrada e saída entre os subprocesos. Tales argumentos non serán pasados ao subproceso (es). En formularios como o nome de ficheiro `` fileName '' pode estar nun argumento separado de `` <'' ou nun mesmo argumento sen espazo intermedio (é dicir, `` < fileName '').
|
Separa os comandos distintos no taboleiro. A saída estándar do comando precedente será incorporada á entrada estándar do seguinte comando.
| & |
Separa os comandos distintos no taboleiro. Tanto a saída estándar como o erro estándar do comando precedente serán entregadas á entrada estándar do seguinte comando. Esta forma de redirección anula formularios como 2> e> &.
< ficheiroName
O ficheiro nomeado por fileName é aberto e usado como entrada estándar para o primeiro comando.
<@ fileId
FileId debe ser o identificador dun ficheiro aberto, como o valor de retorno dunha chamada anterior a abrir . Emprégase como entrada estándar para o primeiro comando. Debe abrirse FileId para ler.
valor <<
O valor pasa ao primeiro comando como entrada estándar.
> ficheiroName
A saída estándar do último comando é redirixida ao ficheiro nomeado fileName , sobrescribindo os seus contidos previos.
2> ficheiroName
O erro estándar de todos os comandos no taboleiro é redirixido ao ficheiro chamado fileName , sobrescribindo os seus contidos previos.
> & ficheiroName
Tanto a saída estándar do último comando como o erro estándar de todos os comandos redirixíronse ao ficheiro chamado fileName , sobrescribindo os seus contidos previos.
>> fileName
A saída estándar do último comando redirixíase ao ficheiro chamado fileName , engadíndose a el en lugar de sobrescribilo.
2 >> ficheiroName
O erro estándar de todos os comandos no taboleiro redirixíase ao ficheiro chamado fileName , engadíndose a el en lugar de sobrescribilo.
>> & ficheiroName
Tanto a saída estándar do último comando como o erro estándar de todos os comandos redirixíronse ao ficheiro chamado fileName , engadíndose a el en lugar de sobrescribilo.
> @ fileId
FileId debe ser o identificador dun ficheiro aberto, como o valor de retorno dunha chamada anterior a abrir . A saída estándar do último comando redirixíase ao arquivo do ficheiro, que debe ser aberto para escribir.
2> @ fileId
FileId debe ser o identificador dun ficheiro aberto, como o valor de retorno dunha chamada anterior a abrir . O erro estándar de todos os comandos no taboleiro é redirixido ao arquivo. Debe abrir o ficheiro para escribir.
> & @ fileId
FileId debe ser o identificador dun ficheiro aberto, como o valor de retorno dunha chamada anterior a abrir . Tanto a saída estándar do último comando coma o erro estándar de todos os comandos son redireccionados ao arquivo. Debe abrir o ficheiro para escribir.
Se a saída estándar non foi redirixida, o comando exec devolve a saída estándar do último comando. Se algún dos comandos na canle saen anormalmente ou son mortos ou suspendidos, o executor devolverá un erro e a mensaxe de erro incluirá a saída da canalización seguida de mensaxes de erro que describen as anulacións anormais; a variable codeCode contén información adicional sobre a última cancelación anormal atopada. Se algún dos comandos escrebe ao seu ficheiro estándar de erro e que o erro estándar non é redirixido, entón o executor devolverá un erro; a mensaxe de erro incluirá a saída estándar da canalización, seguida de mensaxes sobre cancelacións anormais (se hai), seguidas da saída estándar de erro.
Se o último carácter do resultado ou mensaxe de erro é unha liña nova, entón ese carácter normalmente elimínase do resultado ou da mensaxe de erro. Isto é consistente con outros valores de retorno de Tcl, que normalmente non terminan con novas liñas. Non obstante, se se especifica -keepnewline a nova liña final mantense.
Se a entrada estándar non se redirecciona con `` <'' ou `` << '' ou `` <@ '' entón a entrada estándar para o primeiro comando no oleoduto está tomada da entrada estándar actual da aplicación.
Se o último arg é `` & '' entón a tubería executarase en segundo plano. Neste caso, o comando exec dará unha lista cuxos elementos son os identificadores de proceso para todos os subprocesos que se atopan na canle. A saída estándar do último comando na canalización irá á saída estándar da aplicación se non foi redirixida e a saída de erro de todos os comandos no sistema irá ao ficheiro de erro estándar da aplicación a menos que se redireccione.
A primeira palabra en cada comando é tomada como o nome do comando; a tilde-substitution se realiza sobre el, e se o resultado non contén barras, os directorios da variable de entorno PATH son buscados por un nome executable. Se o nome contén unha barra, entón debe referirse a un executable accesible desde o directorio actual. Non se realizan expansións `` glob '' ou outras substitucións con forma de shell nos argumentos a comandos.
Problemas de portabilidade
Windows (todas as versións)
Lendo desde ou escribindo nun socket, usando a notación `` @ fileId '', non funciona. Cando lea desde un socket, unha aplicación DOS de 16 bits colgarase e unha aplicación de 32 bits volverá de inmediato ao final do ficheiro. Cando calquera tipo de aplicación escribe nun socket, a información envíase á consola, se está presente ou se descartou.
O widget de texto da consola Tk non ofrece capacidades reais de IO estándar. En Tk, ao redirigir desde a entrada estándar, todas as aplicacións verán un final de ficheiro inmediato; a información redireccionada á saída estándar ou o erro estándar descartaranse.
As barras dianteiras ou posteriores son aceptadas como separadores de rutas para argumentos nos comandos Tcl. Ao executar unha aplicación, o nome de ruta especificado para a aplicación tamén pode conter barras dianteiras ou posteriores como separadores de rutas. Teña presente, con todo, que a maioría das aplicacións de Windows aceptan argumentos con barras dianteiras só como delimitadores de opción e barras inversas só en camiños. Calquera argumento para unha aplicación que especifique un nome de camiño con barras dianteiras non se converterá automaticamente para usar o carácter de barra invertida. Se un argumento contén barras dianteiras como separador de ruta, pode ou non ser recoñecido como un nome de camiño, dependendo do programa.
Ademais, ao chamar unha aplicación DOS ou Windows 3.x de 16 bits, todos os nomes de camiño deben usar o formato de camiño curto e críptico (por exemplo, usando `` applba ~ 1.def '' en lugar de `` applbakery.default '' ).
Dúas ou máis barras cara atrás ou cara adiante seguidas nunha ruta refírense a unha ruta de rede. Por exemplo, unha simple concatenación do directorio raíz c: / cun subdirectorio / sistema de fiestras dará c: // windows / system (dúas barras xuntas), o que fai referencia ao punto de montaxe chamado sistema na máquina chamada fiestras (e a c: / ignórase), e non é equivalente a c: / windows / system , que describe un directorio na computadora actual. O comando file join debe ser usado para concatenar os compoñentes do camiño.
Windows NT
Ao intentar executar unha aplicación, o executor busca primeiro o nome como se especificou. A continuación, en orde, .com , .exe e .bat están anexadas ao final do nome especificado e busca o nome máis longo. Se non se especificou un nome de directorio como parte do nome da aplicación, os seguintes directorios son automaticamente buscados ao tentar localizar a aplicación:
O directorio desde o que se cargou o executable de Tcl.
O directorio actual.
O directorio de sistema de Windows NT de 32 bits.
O directorio de sistema Windows NT de 16 bits.
O directorio persoal de Windows NT.
Os directorios listados na ruta.
Para executar os comandos integrados no shell como dir e copy , o chamador debe reenviar `` cmd.exe / c '' ao comando desexado.
Windows 95
Ao intentar executar unha aplicación, o executor busca primeiro o nome como se especificou. A continuación, en orde, .com , .exe e .bat están anexadas ao final do nome especificado e busca o nome máis longo. Se non se especificou un nome de directorio como parte do nome da aplicación, os seguintes directorios son automaticamente buscados ao tentar localizar a aplicación:
O directorio desde o que se cargou o executable de Tcl.
O directorio actual.
O directorio do sistema Windows 95.
O directorio persoal de Windows 95.
Os directorios listados na ruta.
Para executar os comandos integrados no shell como dir e copy , o chamador debe prepender `` command.com / c '' ao comando desexado.
Unha vez que unha aplicación DOS de 16 bits leu entrada estándar desde unha consola e despois saia, todas as aplicacións de DOS de 16 bits posteriormente verán a entrada estándar xa pechada. As aplicacións de 32 bits non teñen este problema e funcionarán correctamente, mesmo despois de que unha aplicación DOS de 16 bits pensa que a entrada estándar está pechada. Non hai ningunha solución coñecida para este erro neste momento.
A redirección entre o NUL: dispositivo e unha aplicación de 16 bits non sempre funciona. Cando se redirecciona desde NUL: algunhas aplicacións pódense colgar, outras obterán unha transmisión infinita de bytes `` 0x01 '', e algúns realmente recibirán un remate inmediato de arquivo. o comportamento parece depender de algo compilado na propia aplicación. Ao redirigir máis de 4K a NUL: algunhas aplicacións bloquearanse. Os problemas anteriores non ocorren con aplicacións de 32 bits.
Todas as aplicacións DOS de 16 bits son executadas de forma sincronizada. Toda entrada estándar dun tubo a unha aplicación DOS de 16 bits recóllese nun ficheiro temporal; o outro extremo do tubo debe estar pechado antes de que a aplicación DOS de 16 bits comece a executarse. Todas as saídas estándar ou o erro dunha aplicación DOS de 16 bits a un tubo recóllense en ficheiros temporais; a aplicación debe finalizar antes de que os ficheiros temporais sexan redireccionados á seguinte etapa do oleoduto. Isto débese a unha solución para un erro de Windows 95 na implementación de canalizacións, e é así como o shell estándar de Windows 95 DOS controla os tubos.
Algunhas aplicacións, como command.com , non se deben executar de forma interactiva. As aplicacións que acceden directamente á xanela da consola, en vez de ler dende a súa entrada e escritura estándar ata a súa saída estándar, poden fallar, colgar Tcl ou mesmo colgar o sistema se a súa propia xanela de consola privada non está dispoñible para eles.
Macintosh
O comando exec non está implementado e non existe en Macintosh.
Unix
O comando exec é totalmente funcional e funciona como se describe.
Ver tamén
erro (n), aberto (n)
Palabras clave
executar, canalización, redirección, subproceso
Importante: use o comando man ( % home ) para ver como se usa un comando na súa computadora particular.