En el shell, ¿qué significa "2> & 1"?

2285

En un shell de Unix, si quiero combinar stderry stdouten la stdoutsecuencia para una mayor manipulación, puedo agregar lo siguiente al final de mi comando:

2>&1

Entonces, si quiero usar headen 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.

¿Alguien puede romper esto y explicar carácter por carácter qué 2>&1 significa?

Tristan Havelick
fuente
50
@dbr No creo que sea solo bash, creo que es una cosa de bourne shell; por lo tanto sh, bash, ksh, ash, dash, etc.
armas de fuego
8
Esto es parte del párrafo de redirección que describe shells compatibles con POSIX o POSIX shell para abreviar. ksh es un shell POSIX por ejemplo. Ver: pubs.opengroup.org/onlinepubs/009695399/utilities/…
jim mcnamara
12
Esta construcción también funciona en Windows.
Vadzim
2
Generalmente es mejor hacerlo 2>&1que 2> / dev / null ;-)
F. Hauri
11
Pensé que mencionaría que |& es una forma abreviada de 2>&1 |si estás usando zsh. No puedo hablar sobre si eso se aplica a otros proyectiles tipo bourne o si es una característica de solo zsh.
chrixian

Respuestas:

2557

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

Esta es una manera de recordar este constructo (aunque no es del todo exacto): en un primer momento, 2>1puede parecer una buena manera de redirigir stderra stdout. Sin embargo, en realidad se interpretará como "redirigir stderra un archivo llamado 1". &indica que lo que sigue es un descriptor de archivo y no un nombre de archivo. Por lo que la construcción se convierte en: 2>&1.

Ayman Hourieh
fuente
281
pero entonces, ¿no debería serlo &2>&1?
dokaspar
319
@Dominik: No, &solo se interpreta como "descriptor de archivo" en el contexto de las redirecciones. La escritura command &2>&se analiza como command &y 2>&1, es decir, "ejecuta commanden segundo plano, luego ejecuta el comando 2y redirige su stdout a su stdout".
Adam Rosenfield
15
¿Por qué escogieron cosas tan arcanas como esta? Sólo curioso.
CommaToast
81
Pero, ¿cómo redirigiría stderr a un archivo llamado '& 1'?
Martín Fixman
120
@ Martin:2>'&1'
632
echo test > afile.txt

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

echo test 1> afile.txt

Para redirigir stderr, debes hacer lo siguiente:

echo test 2> afile.txt

>& es la sintaxis para redirigir una secuencia a otro descriptor de archivo: 0 es stdin, 1 es stdout y 2 es stderr.

Puede redirigir 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 &1redirige stderr a stdout.

dbr
fuente
55
¿Tiene algún sentido para ti java ... 2&1 >> data.log? Vi que uno de mis colegas hizo esto.
Thang Pham
55
@Harry que parece un shell que no es bash, o un error tipográfico ... cmd 2>&1 >> somefile.logagregará stdout / stderr a un archivo; es básicamente lo mismo que el anterior, con >> fileagregar
dbr
73
@dbr cmd 2>&1 >>fileno redirige stderr al archivo, pero lo cmd >> file 2>&1hace. El orden importa. En el primer caso, stderr se redirige al stdout del shell (posiblemente un tty si el comando se ingresa de manera interactiva), y luego stdout se dirige al archivo. En el segundo caso, stdout se dirige al archivo y luego stderr se dirige al mismo lugar.
William Pursell
2
Me gusta la respuesta anterior, pero podría ser un poco más clara. "2> & 1" redirige stderr al objetivo de stdout. Entonces, si tiene algo como "ls -l >> directoryContents 2> & 1" El resultado será un archivo llamado directoryContents tendrá el contenido del directorio de trabajo adjunto. Si hay algún error en la ejecución: los mensajes de error también se agregarán al archivo de contenido del directorio, a medida que ocurran.
Max West
1
¿Es 0(or 1,2)>&0(or 1,2)como una opción para controlar la salida? Es echo test >test.log 2>&1igual que echo test 2>&1 >test.log?
Simin Jie
318

Algunos trucos sobre redireccionamiento

Algunas particularidades de sintaxis sobre esto pueden tener comportamientos importantes. Hay algunas pequeñas muestras sobre redirecciones, STDERR, STDOUT, y los argumentos de pedidos .

1 - ¿Sobrescribir o anexar?

Símbolo de redirección> media .

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

En cualquier caso, el archivo se crearía si no existiera.

2 - ¡La línea de comando de shell depende del 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 volca STDERRa la consola, y parece que no es el comportamiento esperado ... Pero ...

Si desea realizar un filtrado posterior sobre 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í parece no ser el comportamiento esperado (por lo tanto, esto podría incluso ser un comportamiento esperado).

Bueno, hay algunos pequeños 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: el &9descriptor ocurriría espontáneamente debido a ) 9>&2.

Anexo: nota!Con la nueva versión de( >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 de este tipo:

$ ((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

Anexo: nota! La misma sintaxis nueva, 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 STDOUTpasar por un filtro específico, STDERRa otro y finalmente ambas salidas fusionadas pasan por un tercer filtro de comando.

3 - Una palabra sobre noclobberopción y >|sintaxis

Eso se trata de sobrescribir :

Si bien le set -o noclobberindica a bash que no sobrescriba ningún archivo existente, la >|sintaxis le permite pasar por 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 con >|:

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

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

Desarmar esta opción y / o preguntar 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 redirigir 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 2>&1existe, también 1>&2es 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

Puede leer el excelente manual presionando:

man -Len -Pless\ +/^REDIRECTION bash

en un consola ;-)

F. Hauri
fuente
55
Lectura adicional: si le gustó esto, puede apreciar: Cómo el abuso de la redirección podría
generar
1
Lecturas adicionales || : Una función para almacenar ambos resultados en variables separadas
F. Hauri
130

Encontré esta brillante publicación sobre redirección: todo sobre redirecciones

Redirigir la salida estándar y el error estándar a un archivo

$ comando &> archivo

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

Así es como se ve la tabla de descriptores de archivos después de que Bash haya redirigido ambas secuencias:

Ingrese la descripción de la imagen aquí

Como puede ver, tanto stdout como stderr ahora apuntan file. Entonces, cualquier cosa escrita en stdout y stderr se escribe en file.

Hay varias formas de redirigir ambas transmisiones al mismo destino. Puede redirigir cada transmisión una tras otra:

$ comando> archivo 2> & 1

Esta es una forma mucho más común de redirigir ambas secuencias a un archivo. Primero stdout se redirige al archivo, y luego stderr se duplica para que sea lo mismo que stdout. Entonces ambas corrientes terminan apuntando a file.

Cuando Bash ve varias redirecciones, las procesa de izquierda a derecha. Veamos los pasos y veamos cómo sucede. Antes de ejecutar cualquier comando, la tabla de descriptores de archivo de Bash se ve así:

Ingrese la descripción de la imagen aquí

Ahora Bash procesa la primera redirección> archivo. Hemos visto esto antes y hace que stdout señale al archivo:

Ingrese la descripción de la imagen aquí

Next Bash ve la segunda redirección 2> & 1. No hemos visto esta redirección antes. Este duplica el descriptor de archivo 2 para que sea una copia del descriptor de archivo 1 y obtenemos:

Ingrese la descripción de la imagen aquí

Ambas transmisiones se han redirigido al archivo.

Sin embargo, ten cuidado aquí! Escritura

comando> archivo 2> & 1

no es lo mismo que escribir:

$ comando 2> & 1> archivo

¡El orden de redireccionamientos importa en Bash! Este comando redirige solo la salida estándar al archivo. El stderr seguirá imprimiéndose en el terminal. Para entender por qué sucede eso, repasemos los pasos nuevamente. Entonces, antes de ejecutar el comando, la tabla de descriptores de archivo se ve así:

Ingrese la descripción de la imagen aquí

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

Ingrese la descripción de la imagen aquí

Ahora Bash ve la segunda redirección >file, y redirige stdout a archivo:

Ingrese la descripción de la imagen aquí

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

También tenga en cuenta que en Bash, escribir

$ comando &> archivo

es exactamente lo mismo que:

$ comando> y archivo

Deen John
fuente
3
Los dos últimos son diferentes si el "comando" termina en un número, ya que eso se toma como descriptor de archivo opcional para>&
MM
Muy bonito dibujo y explicación! ¿Podría explicar qué significa realmente "duplicado"? Usted mencionó: "Este [2> & 1] duplica el descriptor de archivo 2 para que sea una copia del descriptor de archivo 1". Parece que stderr se duplica a stdout. Pero si es el caso, ¿también debería ver err /dev/tty0?
HCSF
87

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.

Puedes mirar /usr/include/unistd.hsi los olvidas:

/* 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 C que usan descriptores de archivo no estándar para el registro personalizado para que no lo vea a menos que lo redirija a un archivo o algo así.

Colin Burnett
fuente
58

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 redirigir cualquier manejador de salida a otro utilizando este método, pero se usa con mayor frecuencia para canalizar stdouty stderrtransmitir en un solo flujo 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 se dirigirá stderra outfile2: lo redirige a lo que stdoutera cuando se encontró el argumento ( outfile1) y luego lo redirige stdouta outfile2.

Esto permite algunos trucos bastante sofisticados.

paxdiablo
fuente
55
Aunque ese último ejemplo sería mucho más claro como: foo> outfile2 2> outfile1
Michael Cramer
3
Más claro, sí, pero eso no mostraría la naturaleza "posicional" de la redirección. El ejemplo está ideado ya que generalmente no es útil hacer esto en una sola línea: el método se vuelve realmente útil cuando diferentes partes son responsables de las diferentes partes de la redirección. Por ejemplo, cuando un script realiza un bit de redireccionamiento y lo ejecuta con otro bit.
paxdiablo
55
Me he dado cuenta de que el último ejemplo también resuelve una confusión desde hace mucho tiempo que había respecto a por qué esto: some_program 2>&1 > /dev/nullno funciona de esta manera: some_program > /dev/null 2>&1.
snapfractalpop
Su comentario sobre el último ejemplo vale sus letras en oro :-) Nunca pensé que estos argumentos de redireccionamiento son posicionales ... Creo que es muy importante saberlo.
Nils-o-mat
20

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


2: Descriptor del 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 xse hace para ser una copia del descriptor de archivo de salida y.

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

La expresión 2>&1copia el descriptor de archivo 1en 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 él".

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

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

wjordan
fuente
19

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 al POSIX.

Por ejemplo, cuando corres

perl test.pl 2>&1

el error estándar se redirige a la salida estándar, por lo que puede 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.

Marcus Thornton
fuente
La segunda muestra es incorrecta: como la orden de precedencia STDERR se redirige a STDOUT , solo se escribirá STDOUT predeterminado en debug.log (no STDERR ). ¡Vea mi respuesta (el párrafo # 2)! Para asegurarse de que ambos sean redirigidos al mismo archivo, debe invertir las directivas de redireccionamiento:perl test.pl > debug.log 2>&1
F. Hauri
16

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

Esto es útil con, por ejemplo, 'más' cuando necesita paginación para toda la salida. Algunos programas les gusta imprimir información de uso en stderr.

Para ayudarte a recordar

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

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

También recomiendo leer esta publicación sobre la redirección de errores donde este tema está cubierto con todo detalle.

Andrioide
fuente
11

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

dup2(1, 2);

Ver la página del manual .

Entender que 2>&1es 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 a file, mientras que el segundo enviará errores a stdout, y la salida ordinaria a file.

ams
fuente
9

Esto es muy útil si eres principiante, lee esto

Actualización:
en Linux o Unix System hay dos lugares a los que los programas envían resultados: Salida estándar (stdout) y Error estándar (stderr) . Puede redirigir estos resultados a cualquier archivo.

Al igual que si hace esto,

ls -a > output.txt

nada se imprimirá en la consola, toda la salida (stdout) se redirige al archivo de salida.

Y si intenta imprimir el contenido de cualquier archivo que no salga significa que la salida será un error como si imprime test.txt que no está presente en el directorio actual La

cat test.txt > error.txt

salida será

cat: test.txt :No such file or directory

Pero el archivo error.txt estará vacío porque redirigimos el stdout a un archivo no stderr.

por lo tanto, necesitamos un descriptor de archivo (un descriptor de archivo no es más que un entero positivo que representa un archivo abierto. Se puede decir que el descriptor es la identificación única del archivo) para decirle a Shell qué tipo de salida estamos enviando al archivo. En el sistema Unix / Linux 1 es para stdout y 2 para stderr .

así que si hace esto,

ls -a 1> output.txtsignifica que está enviando salida estándar (stdout) a output.txt.

y si hace esto

cat test.txt 2> error.txtsignifica que está enviando el Error estándar (stderr) a error.txt.

&1se utiliza para hacer referencia al valor del descriptor de archivo 1 (stdout).

Ahora hasta el punto 2>&1significa "Redirigir el stderr al mismo lugar donde estamos redirigiendo el stdout"

Ahora puedes hacer esto

cat maybefile.txt > output.txt 2>&1

tanto la salida estándar (stdout) como el error estándar (stderr) serán redirigidos a output.txt.

Gracias a Ondrej K. por señalar

Küñdàñ Börà
fuente
1
Las respuestas de solo enlace son problemáticas. El enlace puede quedar inactivo y la respuesta no sirve. Siempre debe incluir suficientes detalles en la respuesta misma.
Ondrej K.
7

La gente, siempre recuerda paxdiablo pista 's acerca de la actual ubicación del objetivo de redirección ... Es es importante.

Mi nemotécnica personal para el 2>&1operador es esta:

  • Piense en &el sentido 'and'o 'add'(el personaje es un amperios - y , ¿verdad?)
  • Entonces se convierte en: 'redirigir 2(stderr) a donde 1(stdout) ya está / actualmente y agregar ambas transmisiones' .

La misma mnemónica funciona también para la otra redirección utilizada con frecuencia 1>&2:

  • Piensa en el &significado ando add... (tienes la idea sobre el signo y, ¿sí?)
  • Entonces se convierte en: 'redirigir 1(stdout) a donde 2(stderr) ya está / actualmente y agregar ambas transmisiones' .

Y recuerde siempre: debe leer las cadenas de redireccionamientos 'desde el final', de derecha a izquierda ( no de izquierda a derecha).

Kurt Pfeifle
fuente
7

Entrada de redireccionamiento

La redirección de entrada hace que el archivo cuyo nombre resulta 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 n no se especifica.

El formato general para redirigir la entrada es:

[n]<word

Salida de redireccionamiento

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

El formato general para redirigir la salida es:

[n]>word

Descriptores de archivos en movimiento

El operador de redireccionamiento,

[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 redireccionamiento

[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 n no se especifica.

Árbitro:

man bash

Escriba /^REDIRECTpara ubicar la redirectionsección y obtenga más información ...

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

PD:

Muchas veces, manera la poderosa herramienta para aprender Linux.

yurenchen
fuente
6

Siempre que /foono exista en su sistema y /tmp...

$ ls -l /tmp /foo

imprimirá el contenido /tmpe imprimirá un mensaje de error para/foo

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

enviará el contenido de /tmpa /dev/nulle imprimir un mensaje de error de/foo

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

hará exactamente lo mismo (tenga en cuenta el 1 )

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

imprimirá el contenido /tmpy 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

Matijs
fuente
5

Esto es como pasar el error al stdout o al terminal.

Es decir, cmdno 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.

Kalanidhi
fuente
1

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

Un consejo : somecmd >1.txt 2>&1es correcto, ¡mientras que somecmd 2>&1 >1.txtestá totalmente equivocado sin ningún efecto!

ch271828n
fuente
1

unix_commands 2>&1

Esto se utiliza para imprimir errores en el terminal.

Lo siguiente ilustra el proceso

  • Cuando se producen errores, se escriben en la &2"memoria intermedia" de la dirección de memoria de error estándar , desde la cual hace 2referencia la secuencia de error estándar .
  • Cuando se produce la salida, se escribe en la dirección de memoria de salida estándar &1"buffer", desde la cual hace 1referencia el flujo de salida estándar .

Por lo tanto, tome el unix_commandsflujo de error estándar 2y redirija >el flujo (de errores) a la dirección de memoria de salida estándar &1, de modo que se transmitan al terminal y se impriman.

tfmontague
fuente