¿Qué significa y significa exactamente en la redirección de salida?

19

Veo cosas como command 1> outo 2>&1para redirigir stderr, pero a veces también veo &>por sí mismo, etc.

¿Cuál es la mejor manera de entender &y qué significa exactamente?

command-line redirect io AJJ
fuente

Respuestas:

26

El &de 2>&1simplemente dice que el número 1es un descriptor de archivo y no un nombre de archivo. En este caso el standard output file descriptor.

Si lo usa 2>1, esto redirigiría los errores a un archivo llamado, 1pero si lo usa 2>&1, lo enviaría al standard output stream.

Esto &>dice enviar ambos standard outputy standard error, en alguna parte. Por ejemplo, ls <non-existent_file> &> out.file. Permítanme ilustrar esto con un ejemplo.

Preparar:

  1. Cree un archivo kokocon el siguiente contenido:

    #!bin/bash

ls j1
echo "koko2"

  2. Hazlo ejecutable: chmod u+x koko

  3. Ahora tenga en cuenta que j1no existe

  4. Ahora corre ./koko &> output

  5. corre cat outputy verás

    ls: cannot access 'j1': No such file or directory
koko2

Ambos, standard error( ls: cannot access 'j1': No such file or directory) y standard output( koko2), fueron enviados al archivo output.

Ahora ejecútelo nuevamente, pero esta vez así:

./koko > output

Hazlo cat outputy solo verás lo koko2mismo. Pero no el resultado de error del ls j1comando. Eso será enviado a standard errorlo que verá en su terminal.

Nota importante gracias a @Byte Commander:

Tenga en cuenta que en command >file 2>&1el orden de la redirección es importante. Si escribe en su command 2>&1 >filelugar (que normalmente no es lo que desea), primero redirigirá los comandos stdoutal archivo y luego redirigirá los comandos stderra su estado no utilizado stdout, por lo que aparecerá en el terminal y podrá canalizarlo o redirigirlo nuevamente, pero no se escribirá en el archivo.

George Udosen
fuente
2
Que &>significa
AJJ
1
Tenga en cuenta que en command >file 2>&1el orden de las redirecciones es importante. Si escribe en su command 2>&1 >filelugar (que normalmente no es lo que desea), primero redirigirá el stdout del comando al archivo y luego redirigirá el stderr del comando a su stdout ahora no utilizado, por lo que aparecerá en la terminal y podrá canalizarlo o redirigirlo nuevamente, pero no se escribirá en el archivo.
Byte Commander
2
"Eso se enviará a standard outputlo que verá en su terminal". ¿No debería ser esto "para el standard error"?
frarugi87
1
Sí @ frarugi87 su derecho corregido
George Udosen
1
@ George wow, fuiste rápido;) Buen trabajo
frarugi87
1

Se [n]>&worddenomina Descriptor de archivos de salida duplicados (consulte la sección 2.7.6 del estándar POSIX Shell Language). Este comportamiento particular es característica de Bourne-como conchas, entre ellos ksh, dashy bash; de hecho, el estándar se basa en Bourne shell y ksh. Al examinar los manuales de tcsh y csh , aparentemente no ofrecen la capacidad de duplicar ningún descriptor de archivo, sin embargo, a partir de la descripción de >&, esto se comporta como &>en bash(es decir, redirige los errores y la salida normal al archivo).

En los sistemas similares a * nix, incluido Ubuntu, a menudo escuchas que todo es un archivo, o más bien un descriptor de archivo . La salida estándar es el descriptor de archivo constante 1 y el error estándar es el descriptor de archivo 2. Entonces, > FILE 2>&1técnicamente significa duplicar el descriptor de archivo 2 en el descriptor de archivo 1. En otras palabras de esta respuesta :

El 2> & 1 le dice al shell que le dé al comando un descriptor de archivo 2 que sea un duplicado del descriptor 1. (es decir, stderr y stdout apuntan al mismo fd).

La clave aquí es tener en cuenta que el descriptor 1 debe configurarse primero. Debido a que el shell procesa las redirecciones en orden de izquierda a derecha, command >FILE 2>&1le dice al shell que vuelva a cablear stdout para commandentrar FILEprimero, y solo entonces el descriptor 2 puede convertirse en una copia de 1, es decir, 1 y 2 apuntan a la misma ubicación FILE.

Por supuesto, esto va más allá del error estándar y la salida estándar. Como se muestra en esta respuesta , haciendo3&>2

... duplicas (dup2) filedescritor 2 en filedescriptor 3, posiblemente cerrando filedescriptor 3 si ya está abierto

Un ejemplo de manipulación de descriptores de archivos, entre muchos, sería capturar la salida del dialogcomando en una variable

También vale la pena señalar que &>es específico para bash. En zshesto se comporta igual, pero según la documentación, "... no tiene el mismo efecto que '> palabra 2> & 1' en presencia de multios". En POSIX compatible /bin/sh, esto se trataría como una redirección regular con poner el comando en segundo plano. Vea también, ¿Hay algún código sh que no sea un código bash sintácticamente válido? .

Ver también:

Sergiy Kolodyazhnyy
fuente