bash shell unix redirect

bash - En la cáscara, ¿qué significa "2> & 1"?



shell unix (15)

En un shell de Unix, si quiero combinar stderr y stdout en la secuencia de stdout para una mayor manipulación, puedo agregar lo siguiente al final de mi comando:

2>&1

Entonces, si quiero usar head en la salida de g++ , puedo hacer algo como esto:

g++ lots_of_errors 2>&1 | head

Así que solo puedo ver los primeros errores.

Siempre tengo problemas para recordar esto, y constantemente tengo que buscarlo, y es principalmente porque no entiendo completamente la sintaxis de este truco en particular.

¿Puede alguien romper esto y explicar carácter por carácter lo que significa 2>&1 ?

Redireccionando entrada

La redirección de la entrada hace que el archivo cuyo nombre resulte de la expansión de la palabra se abra para leer en el descriptor de archivo n, o la entrada estándar (descriptor de archivo 0) si no se especifica n.

El formato general para redireccionar la entrada es:

[n]<word

Salida de redireccionamiento

La redirección de la salida hace que el archivo cuyo nombre resulte de la expansión de la palabra se abra para escribir en el descriptor de archivos n, o la salida estándar (descriptor de archivos 1) si no se especifica n. Si no existe el archivo, se crea; Si existe, se trunca a tamaño cero.

El formato general para redireccionar la salida es:

[n]>word

Descriptores de archivos en movimiento

El operador de redirección,

[n]<&digit-

mueve el dígito del descriptor de archivo al descriptor de archivo n, o la entrada estándar (descriptor de archivo 0) si no se especifica n. dígito se cierra después de ser duplicado a n.

Del mismo modo, el operador de redirección.

[n]>&digit-

mueve el dígito del descriptor de archivo al descriptor de archivo n, o la salida estándar (descriptor de archivo 1) si no se especifica n.

Árbitro:

man bash

Escriba /^REDIRECT para ubicar en la sección de redirection y aprenda más ...

Una versión en línea está aquí: 3.6 Redirecciones

PD:

Muchas veces, el man fue la poderosa herramienta para aprender Linux.

Algunos trucos sobre la redirección

Alguna particularidad de sintaxis sobre esto puede tener comportamientos importantes. Hay algunos ejemplos pequeños sobre redirecciones, STDERR , STDOUT y orden de argumentos.

1 - ¿Sobrescribir o anexar?

Símbolo > redirección media.

  • > significa enviar a como un archivo completo completo , sobrescribiendo el objetivo si existe (vea la función noclobber bash en # 3 más adelante).
  • >> significa enviar además de adjuntar a destino si existe.

En cualquier caso, el archivo sería creado si no existiera.

2 - ¡¡La línea de comandos del shell es dependiente de la orden !!

Para probar esto, necesitamos un comando simple que envíe algo en ambas salidas :

$ ls -ld /tmp /tnt ls: cannot access /tnt: No such file or directory drwxrwxrwt 118 root root 196608 Jan 7 11:49 /tmp $ ls -ld /tmp /tnt >/dev/null ls: cannot access /tnt: No such file or directory $ ls -ld /tmp /tnt 2>/dev/null drwxrwxrwt 118 root root 196608 Jan 7 11:49 /tmp

(Esperando que no tenga un directorio llamado /tnt , por supuesto;). Bueno, lo tenemos !!

Entonces, veamos:

$ ls -ld /tmp /tnt >/dev/null ls: cannot access /tnt: No such file or directory $ ls -ld /tmp /tnt >/dev/null 2>&1 $ ls -ld /tmp /tnt 2>&1 >/dev/null ls: cannot access /tnt: No such file or directory

La última línea de comando vuelca STDERR a la consola, y parece que no es el comportamiento esperado ... Pero ...

Si desea realizar un filtrado posterior de una salida, la otra o ambas:

$ ls -ld /tmp /tnt | sed ''s/^.*$/<-- & --->/'' ls: cannot access /tnt: No such file or directory <-- drwxrwxrwt 118 root root 196608 Jan 7 12:02 /tmp ---> $ ls -ld /tmp /tnt 2>&1 | sed ''s/^.*$/<-- & --->/'' <-- ls: cannot access /tnt: No such file or directory ---> <-- drwxrwxrwt 118 root root 196608 Jan 7 12:02 /tmp ---> $ ls -ld /tmp /tnt >/dev/null | sed ''s/^.*$/<-- & --->/'' ls: cannot access /tnt: No such file or directory $ ls -ld /tmp /tnt >/dev/null 2>&1 | sed ''s/^.*$/<-- & --->/'' $ ls -ld /tmp /tnt 2>&1 >/dev/null | sed ''s/^.*$/<-- & --->/'' <-- ls: cannot access /tnt: No such file or directory --->

Tenga en cuenta que la última línea de comando en este párrafo es exactamente la misma que en el párrafo anterior, donde escribí no parece ser el comportamiento esperado (por lo tanto, esto podría ser un comportamiento esperado).

Bueno, hay algunos trucos sobre las redirecciones, para realizar diferentes operaciones en ambas salidas :

$ ( ls -ld /tmp /tnt | sed ''s/^/O: /'' >&9 ) 9>&2 2>&1 | sed ''s/^/E: /'' O: drwxrwxrwt 118 root root 196608 Jan 7 12:13 /tmp E: ls: cannot access /tnt: No such file or directory

Nota: &9 descriptor ocurriría espontáneamente debido a ) 9>&2 .

Adición: ¡nota! Con la nueva versión de bash ( >4.0 ) hay una nueva característica y una sintaxis más sexy para hacer este tipo de cosas:

$ ls -ld /tmp /tnt 2> >(sed ''s/^/E: /'') > >(sed ''s/^/O: /'') O: drwxrwxrwt 17 root root 28672 Nov 5 23:00 /tmp E: ls: cannot access /tnt: No such file or directory

Y, finalmente, para un formato de salida en cascada:

$ ((ls -ld /tmp /tnt |sed ''s/^/O: /'' >&9 ) 2>&1 |sed ''s/^/E: /'') 9>&1| cat -n 1 O: drwxrwxrwt 118 root root 196608 Jan 7 12:29 /tmp 2 E: ls: cannot access /tnt: No such file or directory

Adición: ¡nota! La misma nueva sintaxis, en ambos sentidos:

$ cat -n <(ls -ld /tmp /tnt 2> >(sed ''s/^/E: /'') > >(sed ''s/^/O: /'')) 1 O: drwxrwxrwt 17 root root 28672 Nov 5 23:00 /tmp 2 E: ls: cannot access /tnt: No such file or directory

Donde STDOUT atraviesa un filtro específico, STDERR a otro y finalmente ambas salidas combinadas pasan a través de un tercer filtro de comando.

3 - Una palabra acerca de la opción noclobber y >| sintaxis

Eso es sobre sobrescribir :

Mientras se set -o noclobber indica a bash que no sobrescriba ningún archivo existente, el >| la sintaxis le permite pasar a través de esta limitación:

$ testfile=$(mktemp /tmp/testNoClobberDate-XXXXXX) $ date > $testfile ; cat $testfile Mon Jan 7 13:18:15 CET 2013 $ date > $testfile ; cat $testfile Mon Jan 7 13:18:19 CET 2013 $ date > $testfile ; cat $testfile Mon Jan 7 13:18:21 CET 2013

El archivo se sobrescribe cada vez, bueno ahora:

$ set -o noclobber $ date > $testfile ; cat $testfile bash: /tmp/testNoClobberDate-WW1xi9: cannot overwrite existing file Mon Jan 7 13:18:21 CET 2013 $ date > $testfile ; cat $testfile bash: /tmp/testNoClobberDate-WW1xi9: cannot overwrite existing file Mon Jan 7 13:18:21 CET 2013

Pase a través de >| :

$ date >| $testfile ; cat $testfile Mon Jan 7 13:18:58 CET 2013 $ date >| $testfile ; cat $testfile Mon Jan 7 13:19:01 CET 2013

Desactivando esta opción y / o preguntando si ya está configurado.

$ set -o | grep noclobber noclobber on $ set +o noclobber $ set -o | grep noclobber noclobber off $ date > $testfile ; cat $testfile Mon Jan 7 13:24:27 CET 2013 $ rm $testfile

4 - Último truco y más ...

Para redireccionar ambos resultados de un comando dado, vemos que una sintaxis correcta podría ser:

$ ls -ld /tmp /tnt >/dev/null 2>&1

para este caso especial , hay una sintaxis de acceso directo: &> ... o >&

$ ls -ld /tmp /tnt &>/dev/null $ ls -ld /tmp /tnt >&/dev/null

Nota: si existen 2>&1 , 1>&2 es una sintaxis correcta:

$ ls -ld /tmp /tnt 2>/dev/null 1>&2

4b- Ahora, te dejaré pensar en:

$ ls -ld /tmp /tnt 2>&1 1>&2 | sed -e s/^/++/ ++/bin/ls: cannot access /tnt: No such file or directory ++drwxrwxrwt 193 root root 196608 Feb 9 11:08 /tmp/ $ ls -ld /tmp /tnt 1>&2 2>&1 | sed -e s/^/++/ /bin/ls: cannot access /tnt: No such file or directory drwxrwxrwt 193 root root 196608 Feb 9 11:08 /tmp/

4c- Si estás interesado en más información.

Podrías leer el fino manual pulsando:

man -Len -Pless/ +/^REDIRECTION bash

en una consola de bash ;-)

0 para entrada, 1 para stdout y 2 para stderr.

Un consejo : somecmd >1.txt 2>&1 es correcto, mientras que somecmd 2>&1 >1.txt es totalmente incorrecto sin ningún efecto.

2 es el error estándar de la consola.

1 es la salida estándar de la consola.

Este es el Unix estándar, y Windows también sigue el POSIX.

Por ejemplo, cuando corres

perl test.pl 2>&1

el error estándar se redirige a la salida estándar, para que pueda ver ambas salidas juntas:

perl test.pl > debug.log 2>&1

Después de la ejecución, puede ver todos los resultados, incluidos los errores, en el debug.log.

perl test.pl 1>out.log 2>err.log

Luego, la salida estándar va a out.log y el error estándar a err.log.

Te sugiero que trates de entender esto.

Desde el punto de vista de un programador, significa precisamente esto:

dup2(1, 2);

Ver la página del manual .

Entender que 2>&1 es una copia también explica por qué ...

command >file 2>&1

... no es lo mismo que ...

command 2>&1 >file

El primero enviará ambas secuencias al file , mientras que el segundo enviará los errores a la salida file y la salida ordinaria al file .

El descriptor de archivo 1 es la salida estándar ( stdout ).
El descriptor de archivo 2 es el error estándar ( stderr ).

Aquí hay una forma de recordar esta construcción (aunque no es del todo precisa): al principio, 2>1 puede parecer una buena forma de redirigir stderr a stdout . Sin embargo, en realidad se interpretará como "redireccionamiento stderr a un archivo llamado 1 ". & indica que lo que sigue es un descriptor de archivo y no un nombre de archivo. Así que la construcción se convierte en: 2>&1 .

Encontré este brillante post sobre redirección: Todo sobre redirecciones.

Redirigir tanto la salida estándar como el error estándar a un archivo

$ comando &> archivo

Este one-liner usa el operador &> para redireccionar ambas secuencias de salida - stdout y stderr - desde el comando al archivo. Este es el acceso directo de Bash para redireccionar rápidamente ambas transmisiones al mismo destino.

Aquí es cómo se ve la tabla del descriptor de archivos después de que Bash ha redirigido ambas secuencias:

Como puede ver, tanto stdout como stderr ahora apuntan al file . Así que cualquier cosa escrita en stdout y stderr se escribe en un file .

Hay varias formas de redireccionar ambas transmisiones al mismo destino. Puedes redireccionar cada secuencia una tras otra:

$ comando> archivo 2> & 1

Esta es una forma mucho más común de redireccionar ambas secuencias a un archivo. La primera salida estándar se redirige al archivo, y luego stderr se duplica para que sea igual que la salida estándar. Así que ambas secuencias terminan apuntando al file .

Cuando Bash ve varias redirecciones, las procesa de izquierda a derecha. Vayamos a través de los pasos y veamos cómo sucede eso. Antes de ejecutar cualquier comando, la tabla del descriptor de archivos de Bash se ve así:

Ahora Bash procesa el primer archivo de redirección. Hemos visto esto antes y hace que stdout sea un punto para archivar:

Siguiente Bash ve la segunda redirección 2> & 1. No hemos visto esta redirección antes. Éste duplica el descriptor de archivo 2 para ser una copia del descriptor de archivo 1 y obtenemos:

Ambas transmisiones han sido redirigidas a archivo.

Sin embargo ten cuidado aquí! Escritura

comando> archivo 2> & 1

no es lo mismo que escribir:

$ comando 2> & 1> archivo

El orden de redirecciones importa en Bash! Este comando redirige solo la salida estándar al archivo. El stderr todavía se imprimirá en el terminal. Para entender por qué sucede eso, repasemos los pasos nuevamente. Así que antes de ejecutar el comando, la tabla del descriptor de archivo se ve así:

Ahora Bash procesa redirecciones de izquierda a derecha. Primero ve 2> & 1 por lo que duplica stderr a stdout. La tabla de descriptores de archivos se convierte en:

Ahora Bash ve el segundo redireccionamiento, >file , y redirige stdout a archivo:

¿Ves lo que pasa aquí? ¡Stdout ahora apunta al archivo, pero el stderr todavía apunta al terminal! ¡Todo lo que se escribe en stderr todavía se imprime en la pantalla! ¡Así que ten mucho cuidado con el orden de redirecciones!

También tenga en cuenta que en Bash, escribiendo

$ comando &> archivo

es exactamente lo mismo que:

$ comando> y archivo

Esa construcción envía el flujo de error estándar ( stderr ) a la ubicación actual de la salida estándar ( stdout ): este problema de moneda parece haber sido descuidado por las otras respuestas.

Puede redireccionar cualquier controlador de salida a otro usando este método, pero se usa con más frecuencia para canalizar stdout y stderr streams en un solo stream para su procesamiento.

Algunos ejemplos son:

# Look for ERROR string in both stdout and stderr. foo 2>&1 | grep ERROR # Run the less pager without stderr screwing up the output. foo 2>&1 | less # Send stdout/err to file (with append) and terminal. foo 2>&1 |tee /dev/tty >>outfile # Send stderr to normal location and stdout to file. foo >outfile1 2>&1 >outfile2

Tenga en cuenta que el último no dirigirá stderr a outfile2 , sino que lo redirige a lo que stdout era cuando se encontró el argumento ( outfile1 ) y luego redirige stdout a outfile2 .

Esto permite algunos trucos bastante sofisticados.

Esto es como pasar el error a la salida estándar o al terminal.

Es decir, cmd no es un comando:

$cmd 2>filename cat filename command not found

El error se envía al archivo de esta manera:

2>&1

El error estándar se envía al terminal.

Gente, siempre recuerde la sugerencia de paxdiablo sobre la ubicación actual del objetivo de redirección ... Es importante.

Mi mnemotecnia personal para el operador 2>&1 es esta:

  • Piense en & como que significa ''and'' o ''add'' (el personaje es un símbolo - y , ¿no es así?)
  • Entonces se convierte en: ''redirigir 2 (stderr) a donde 1 (stdout) ya está / actualmente y agregar ambas secuencias'' .

La misma mnemotécnica también funciona para la otra redirección utilizada con frecuencia, 1>&2 :

  • Piense en & significado and o o add ... (tiene la idea del símbolo, ¿sí?)
  • Entonces se convierte en: ''redirigir 1 (stdout) a donde 2 (stderr) ya está / actualmente y agregar ambas secuencias'' .

Y siempre recuerda: tienes que leer las cadenas de redirecciones ''desde el final'', de derecha a izquierda ( no de izquierda a derecha).

Los números se refieren a los descriptores de archivo (fd).

  • Cero es stdin
  • Uno es stdout
  • Dos es stderr

2>&1 redirige fd 2 a 1.

Esto funciona para cualquier número de descriptores de archivos si el programa los usa.

Puede mirar /usr/include/unistd.h si los olvida:

/* Standard file descriptors. */ #define STDIN_FILENO 0 /* Standard input. */ #define STDOUT_FILENO 1 /* Standard output. */ #define STDERR_FILENO 2 /* Standard error output. */

Dicho esto, he escrito herramientas en C que utilizan descriptores de archivos no estándar para el registro personalizado, por lo que no lo verá a menos que lo redirija a un archivo o algo.

Para responder a su pregunta: Toma cualquier salida de error (normalmente enviada a stderr) y la escribe en la salida estándar (stdout).

Esto es útil con, por ejemplo, ''más'' cuando necesita paginación para todos los resultados. A algunos programas les gusta imprimir información de uso en stderr.

Para ayudarte a recordar

  • 1 = salida estándar (donde los programas imprimen salida normal)
  • 2 = error estándar (donde los programas imprimen errores)

"2> & 1" simplemente apunta todo lo enviado a stderr, a stdout en su lugar.

También recomiendo leer esta publicación en caso de error redirigiendo donde se cubre este tema con todo detalle.

Siempre que /foo no exista en su sistema y /tmp no ...

$ ls -l /tmp /foo

imprimirá el contenido de /tmp e imprimirá un mensaje de error para /foo

$ ls -l /tmp /foo > /dev/null

enviará el contenido de /tmp a /dev/null e imprimirá un mensaje de error para /foo

$ ls -l /tmp /foo 1> /dev/null

hará exactamente lo mismo (note el 1 )

$ ls -l /tmp /foo 2> /dev/null

imprimirá el contenido de /tmp y enviará el mensaje de error a /dev/null

$ ls -l /tmp /foo 1> /dev/null 2> /dev/null

enviará tanto el listado como el mensaje de error a /dev/null

$ ls -l /tmp /foo > /dev/null 2> &1

es taquigrafía

2>&1 es una construcción de shell POSIX. Aquí hay un desglose, token por token:

2 : Descriptor de archivo de salida " error estándar ".

>& : Duplicar un operador descriptor de archivo de salida (una variante del operador de redirección de salida > ). Dado [x]>&[y] , el descriptor de archivo indicado por x se convierte en una copia del descriptor de archivo de salida y .

1 descriptor de archivo de salida "Salida estándar ".

La expresión 2>&1 copia el descriptor de archivo 1 en la ubicación 2 , por lo que cualquier salida escrita en 2 ("error estándar") en el entorno de ejecución va al mismo archivo descrito originalmente por 1 ("salida estándar").

Explicación adicional:

Descriptor de archivo : "Un entero único, no negativo por proceso, utilizado para identificar un archivo abierto con el fin de acceder a un archivo".

Salida / error estándar : consulte la siguiente nota en la sección Redirection de la documentación del shell:

Los archivos abiertos están representados por números decimales que comienzan con cero. El valor más grande posible está definido por la implementación; sin embargo, todas las implementaciones deben admitir al menos 0 a 9, inclusive, para el uso de la aplicación. Estos números se denominan "descriptores de archivo". Los valores 0, 1 y 2 tienen un significado especial y usos convencionales y están implícitos en ciertas operaciones de redirección; se les conoce como entrada estándar, salida estándar y error estándar, respectivamente. Los programas usualmente toman su entrada de la entrada estándar y escriben la salida en la salida estándar. Los mensajes de error se escriben generalmente en error estándar. Los operadores de redirección pueden ir precedidos por uno o más dígitos (sin caracteres intermedios permitidos) para designar el número del descriptor de archivo.

echo test > afile.txt

redirige stdout a afile.txt . Esto es lo mismo que hacer

echo test 1> afile.txt

Para redireccionar stderr, usted hace:

echo test 2> afile.txt

>& es la sintaxis para redirigir un flujo a otro descriptor de archivo: 0 es estándar, 1 es stdout y 2 es stderr.

Puedes redireccionar stdout a stderr haciendo:

echo test 1>&2 # or echo test >&2

O viceversa:

echo test 2>&1

Entonces, en resumen ... 2> redirige stderr a un archivo (no especificado), agregando &1 redirige stderr a stdout.