exec – Invocar subprocesos
Índice de contenidos
Sinopsis
exec ? cambia ? arg ? arg …?
Descripción
Este comando trata sus argumentos como la especificación de uno o más subprocesos a ejecutar. Los argumentos toman la forma de un shell pipeline estándar donde cada arg se convierte en una palabra de un comando, y cada comando distinto se convierte en un subproceso.
Si los argumentos iniciales para exec comienzan con – entonces se tratan como modificadores de línea de comandos y no son parte de la especificación de la tubería. Actualmente se admiten los siguientes conmutadores:
-keepnewline
Mantiene una nueva línea de arrastre en la salida del oleoducto. Normalmente se borrará una nueva línea de arrastre.
—
Marca el final de los interruptores. El argumento que sigue a éste será tratado como el primero arg incluso si comienza con un – .
Si un arg (o un par de arg‘s) tiene uno de los formularios descritos a continuación, es utilizado por exec para controlar el flujo de entrada y salida entre los subprocesos. Dichos argumentos no se pasarán a los subprocesos. En formularios como «< fileName»’. fileName puede estar en un argumento separado de «<'' o en el mismo argumento sin espacio intermedio (i.e. ``< fileName»).
|
Separa los distintos comandos en la tubería. La salida estándar del comando anterior se canalizará hacia la entrada estándar del siguiente comando.
|DIFUNDE LA PALABRA-
Separa los distintos comandos en la tubería. Tanto la salida estándar como el error estándar del comando anterior se canalizarán a la entrada estándar del siguiente comando. Esta forma de redirección anula formas como 2> y>&&&
fileName
El archivo nombrado por fileName se abre y se utiliza como entrada estándar para el primer comando en el pipeline.
fileId
FileId debe ser el identificador de un archivo abierto, como el valor de retorno de una llamada anterior a open . Se utiliza como entrada estándar para el primer comando del pipeline. FileIddebe haber sido abierto para su lectura.
valor
El valor se pasa al primer comando como entrada estándar.
fileName
La salida estándar del último comando se redirige al archivo llamado fileName, sobrescribiendo su contenido anterior.
2> fileName
El error estándar de todos los comandos en el pipeline se redirige al archivo llamado fileName, sobrescribiendo su contenido anterior.
fileName
Tanto la salida estándar del último comando como el error estándar de todos los comandos se redirigen al archivo llamado fileName, sobrescribiendo su contenido anterior.
fileName
La salida estándar del último comando se redirige al archivo llamado fileName, añadiendo a él en lugar de sobrescribirlo.
2>> fileName
El error estándar de todos los comandos en el pipeline se redirige al archivo llamado fileName, añadiendo a él en lugar de sobrescribirlo.
& fileName
Tanto la salida estándar del último comando como el error estándar de todos los comandos se redirigen al archivo llamado fileName, añadiéndole en lugar de sobrescribirlo.
fileId
FileId debe ser el identificador de un archivo abierto, como el valor de retorno de una llamada anterior a open . La salida estándar del último comando se redirige al archivo fileId‘s file, que debe haber sido abierto para su escritura.
2>@ fileId
FileId debe ser el identificador de un archivo abierto, como el valor de retorno de una llamada anterior a open . El error estándar de todos los comandos en el pipeline se redirige al archivo fileId‘s file. El archivo debe haber sido abierto para su escritura.
fileId
FileId debe ser el identificador de un archivo abierto, como el valor de retorno de una llamada anterior a open . Tanto la salida estándar del último comando como el error estándar de todos los comandos se redirigen al archivo fileId‘s file. El archivo debe haber sido abierto para su escritura.
Si la salida estándar no ha sido redirigida, entonces el comando exec devuelve la salida estándar desde el último comando en el pipeline. Si alguno de los comandos en la salida de la tubería se mata o suspende anormalmente, entonces exec devolverá un error y el mensaje de error incluirá la salida de la tubería seguida de mensajes de error que describan las terminaciones anormales; la variable errorCode contendrá información adicional sobre la última terminación anormal encontrada. Si alguno de los comandos escribe en su archivo de error estándar y ese error estándar no es redirigido, entonces exec devolverá un error; el mensaje de error incluirá la salida estándar de la tubería, seguida de mensajes sobre terminaciones anormales (si las hubiera), seguidos de la salida de error estándar.
Si el último carácter del resultado o mensaje de error es una nueva línea, normalmente se borra del resultado o mensaje de error. Esto es consistente con otros valores de retorno Tcl, que normalmente no terminan con líneas nuevas. Sin embargo, si -keepnewline está especificado, entonces la nueva línea de arrastre se mantiene.
Si la entrada estándar no se redirige con «<'' o ```<<'' o ```<@'' entonces la entrada estándar para el primer comando en el pipeline se toma de la entrada estándar actual de la aplicación.
Si el último arg es «&»’ entonces la tubería se ejecutará en segundo plano. En este caso el comando exec devolverá una lista cuyos elementos son los identificadores de proceso para todos los subprocesos del pipeline. La salida estándar del último comando en el pipeline irá a la salida estándar de la aplicación si no ha sido redirigida, y la salida de error de todos los comandos en el pipeline irá al archivo de error estándar de la aplicación a menos que sea redirigida.
La primera palabra de cada comando se toma como el nombre del comando; se realiza la sustitución de tilde, y si el resultado no contiene barras, entonces los directorios de la variable de entorno PATH son buscados por un ejecutable con el nombre dado. Si el nombre contiene una barra oblicua, debe referirse a un ejecutable accesible desde el directorio actual. No se realiza ninguna expansión de «`glob» u otras sustituciones similares a shell en los argumentos de los comandos.
Problemas de portabilidad
Windows (todas las versiones)
Leer desde o escribir en un socket, usando la notación «` @ fileId»’, no funciona. Cuando se lee desde un socket, una aplicación DOS de 16 bits se cuelga y una aplicación de 32 bits regresa inmediatamente con el fin del archivo. Cuando cualquier tipo de aplicación escribe en un socket, la información es enviada a la consola, si está presente, o es descartada.
El widget de texto de la consola Tk no proporciona capacidades de E/S estándar reales. En Tk, cuando se redirige desde una entrada estándar, todas las aplicaciones verán un fin de archivo inmediato; la información redirigida a la salida estándar o al error estándar se descartará.
Se aceptan barras oblicuas hacia adelante o hacia atrás como separadores de ruta para los argumentos de los comandos Tcl. Al ejecutar una aplicación, el nombre de ruta especificado para la aplicación también puede contener barras oblicuas hacia adelante o hacia atrás como separadores de ruta. Tenga en cuenta, sin embargo, que la mayoría de las aplicaciones de Windows aceptan argumentos con barras oblicuas sólo como delimitadores de opciones y barras oblicuas sólo en las rutas. Cualquier argumento de una aplicación que especifique un nombre de ruta con barras oblicuas no se convertirá automáticamente para utilizar el carácter de barra invertida. Si un argumento contiene barras oblicuas como separador de ruta, puede o no ser reconocido como nombre de ruta, dependiendo del programa.
Además, cuando se llama a una aplicación DOS de 16 bits o Windows 3.X, todos los nombres de rutas deben usar el formato de ruta corto y críptico (por ejemplo, usando «`applba~1.def» en lugar de «`applbakery.default»).
Dos o más barras oblicuas hacia adelante o hacia atrás en una fila de una ruta se refieren a una ruta de red. Por ejemplo, una simple concatenación del directorio raíz c:/ con un subdirectorio /windows/system producirá c:// (dos barras oblicuas juntas), que se refiere al punto de montaje llamado system en la máquina llamada windows (y el c:/ es ignorado), y no es equivalente a c:/ c:/windows/system , que describe un directorio en el ordenador actual. El comando file join debe utilizarse para concatenar los componentes de la ruta.
Windows NT
Cuando se intenta ejecutar una aplicación, exec primero busca el nombre tal como se especificó. Luego, en orden, .com , .exe , y .bat se añaden al final del nombre especificado y busca el nombre más largo. Si no se ha especificado un nombre de directorio como parte del nombre de la aplicación, se buscarán automáticamente los siguientes directorios en orden cuando se intente localizar la aplicación:
El directorio desde el que se cargó el ejecutable Tcl.El directorio actual.
El directorio de sistema de 32 bits de Windows NT.El directorio de sistema de 16 bits de Windows NT.El directorio principal de Windows NT.Los directorios listados en la ruta.
Para ejecutar los comandos shell builtin como dir y copy , la persona que llama debe anteponer « cmd.exe /c » al comando deseado.
Windows 95
Cuando se intenta ejecutar una aplicación, exec primero busca el nombre tal como se especificó. Luego, en orden, .com , .exe , y .bat se añaden al final del nombre especificado y busca el nombre más largo. Si no se ha especificado un nombre de directorio como parte del nombre de la aplicación, se buscarán automáticamente los siguientes directorios en orden cuando se intente localizar la aplicación:
El directorio desde el que se cargó el ejecutable Tcl.El directorio actual.
El directorio de sistema de Windows 95.
El directorio raíz de Windows 95.
Los directorios listados en la ruta.
Para ejecutar los comandos shell builtin como dir y copy , la persona que llama debe prepender « command.com /c » al comando deseado.
Una vez que una aplicación DOS de 16 bits haya leído la entrada estándar de una consola y luego la haya cerrado, todas las aplicaciones DOS de 16 bits que se ejecuten posteriormente verán la entrada estándar como ya cerrada. Las aplicaciones de 32 bits no tienen este problema y funcionarán correctamente, incluso después de que una aplicación de DOS de 16 bits piense que la entrada estándar está cerrada. No se conoce ninguna solución para este error en este momento.
La redirección entre el dispositivo NUL: y una aplicación de 16 bits no siempre funciona. Al redirigir desde NUL: , algunas aplicaciones pueden colgarse, otras obtendrán un flujo infinito de bytes «`0x01», y algunas obtendrán realmente un final de archivo inmediato; el comportamiento parece depender de algo compilado en la propia aplicación. Cuando se redirige más de 4K o así a NUL: , algunas aplicaciones se colgarán. Los problemas anteriores no ocurren con las aplicaciones de 32 bits.
Todas las aplicaciones DOS de 16 bits se ejecutan sincrónicamente. Toda la entrada estándar de un tubo a una aplicación DOS de 16 bits se recoge en un archivo temporal; el otro extremo del tubo debe cerrarse antes de que la aplicación DOS de 16 bits comience a ejecutarse. Toda la salida estándar o error de una aplicación DOS de 16 bits a una tubería se recoge en archivos temporales; la aplicación debe terminar antes de que los archivos temporales sean redirigidos a la siguiente etapa de la tubería. Esto se debe a un error de Windows 95 en la implementación de tuberías, y es la forma en que el shell estándar de Windows 95 DOS maneja las tuberías en sí.
Algunas aplicaciones, como command.com , no deberían ejecutarse de forma interactiva. Las aplicaciones que acceden directamente a la ventana de la consola, en lugar de leer desde su entrada estándar y escribir en su salida estándar, pueden fallar, colgar Tcl, o incluso colgar el sistema si su propia ventana de consola privada no está disponible para ellos.
Macintosh
El comando exec no está implementado y no existe en Macintosh.
Unix
El comando exec es completamente funcional y funciona como se describe.
Ver también
error(n), open(n)
Palabras clave
execute, pipeline, redirection, subprocess
Utilice el comando man ( % man) para ver cómo se utiliza un comando en su equipo particular.
