¿Cómo puedo recordar cómo usar la redirección?

40

yo se que

  program > /dev/null 2>&1

hace. Redirige la salida hacia /dev/nully 2>&1significa redirigir la salida de error en el mismo lugar donde se envía la salida.

Mi problema es que siempre tengo que buscarlo en Google porque nunca lo recuerdo.

Por lo tanto, trato &2>1, 1>2&, 1>&2... Trato todas las combinaciones hasta que Google él ...

¿Cuál es el truco para recordarlo fácilmente?

shell

— Luc M
fuente

Tengo el mismo problema, así que lo hago a la manera "larga": redirigir ambos program 1> /dev/null 2>/dev/null. Algunas veces, sin embargo, es necesario mezclar stdouty stderrjuntos para ver lo que realmente está sucediendo, como el resultado de un complejo proceso de compilación que se redirige a un archivo. En ese caso, termino

— buscando en

20

La salida es mejor que el error, por lo que viene primero (1 vs 2).

>es la abreviatura de 'va a'. A la izquierda es lo que quiero enviar y a la derecha es donde quiero enviarlo. Dado que 'donde' es (casi) siempre un archivo, algo así como

program > /dev/null 2>1

redirigiría a un archivo llamado 1. Por lo tanto, el ampersand (&)modifica el archivo al descriptor de archivo.

Desafortunadamente, no he encontrado ni desarrollado mi propia mnemónica, pero cuando aprendí * nix, encontré esta forma lógica de trabajar bien. Después de algunos recorridos, se convierte en una segunda naturaleza.

— gvkv
fuente

Tu primera oración no tiene sentido para mí. stdoutes el descriptor de archivo 1, stderres 2. Entonces, "error" viene antes de "salida".

— Warren Young

Esa oración es un mnemotécnico para recordar qué descriptor de archivo stdouty stderrreferir.

— gvkv

Está bien, pero aún parece confuso, ya que la pregunta original es sobre tratar de recordar el orden de los caracteres en el encantamiento "2> & 1".

— Warren Young

9

Un truco es recordar que 1 = salida estándar, 2 = error estándar. Asi que:

2>&1= la secuencia de error estándar entra en la secuencia de salida estándar.
1>&2= viceversa.

Si alguna vez ha programado en un lenguaje similar a C, es fácil recordar el signo y ( &). Elijo pensar que se refiere a la "dirección del" descriptor de archivo existente, para que no cambie el archivo en sí mismo ni cree uno nuevo.

— Thronic
fuente

7

Verlo &como un nudo podría ayudar: piense en lo que quiere hacer tomando la salida de 2, entonces 2>, y vinculándola con 1, entonces2>&1

— Bertrand Lorentz
fuente

2

Acabo de memorizar la frase "dos fuera y uno". Si tu mnemotécnico es una frase o un nudo, tener uno realmente te ayudará.

— Tim Kennedy el

5

En realidad, depende de qué shell estés usando. Bash suele ser muy indulgente y puedes hacer lo siguiente:

program &> file

— Kevin Cantu
fuente

5

Consideremos estas tres opciones:

program  2>1
program  2>1& 
program  2>&1

El primero envía stderr a los nombres de archivo "1": después de todo, bash espera redirigir a un archivo.

El segundo también redirige al mismo archivo pero se ejecuta programen segundo plano: eso es lo que &se supone que significa un final .

Eso deja la tercera posibilidad como la única que tiene sentido en el universo bash para redirigir a un identificador de archivo.

¿Cómo recordar cuál es cuál entre 0, 1, 2? Piense en ejecutar una computadora desde la consola. Primero, debe escribir algo (0 = stdin). Entonces, ves salida (1 = stdout). Por último y solo si algo sale mal, verá stderr (2).

— John1024
fuente

1

Dibújala en tu fondo de pantalla.

Ahora, en serio, esta y otras cosas básicas que olvidé, así que agregué un menú de consejos rápidos a una aplicación que desarrollé y que uso a diario. Es posible que desee probarlo o usar algo como gnote para mantener una nota.

— Ubersoldat
fuente

1

En lo que respecta al shell bash, creo que la mejor manera de recordar es entender lo que está sucediendo.
Si todo lo que quiere hacer es recordar cómo obtener el comando correcto, puede intentar

program > /results 2> /results

Eso es agradable y obvio, y fácil de recordar. es decir

1 STDOUT va a /results
2STDERR también va directamente a/results

El problema es que esto no funciona como cabría esperar. considera lo siguiente:

archivo: /tmp/poem.txt

the quick brown fox jumped over the lazy dog

y el ejecutar el comando

grep "brown" /tmp/poem.txt NOT_A_FILE > /tmp/results 2> /tmp/results

luego

$ cat /tmp/results
grep: NOT_A_FILE: No such file or directory
 lazy dog

¿lo que pasó aquí?
Tengo entendido que bash configuró la redirección apuntando el STDERR directamente al archivo /tmp/resultsy debido a la naturaleza de lo >que hace 2 cosas

normalmente crea un nuevo archivo; en este caso, la oportunidad ha pasado ya que bash ha superado esta rutina en el momento en que se genera la salida.
inserte directamente en el comienzo del archivo. y no agregar como lo >>hace.

Entonces, en este caso, STDERR, se inserta directamente al comienzo de /tmp/resultsanular la salida de STDOUT.
Nota: si solía >>agregar, probablemente podría salirse con esta sintaxis.
Sin embargo, para solucionar el problema que necesita, no para redirigir STDERR, al archivo directamente, sino para fusionar la salida de STDERR en la secuencia STDOUT, para que no se produzca una colisión.
El uso del operador 2>&1operador logra esto

grep "brown" poem.txt NOT_A_FILE > /tmp/results 2>&1

El &permite fiesta de distinguir de un archivo con el nombre 1y el 1descriptor de archivo.
Para mí, la declaración en 2>&1sí misma explica exactamente lo que está sucediendo: STDERR se está redirigiendo a STDOUT en sí mismo, y solo termina /tmp/resultsporque allí es donde apunta STDOUT (casi como un efecto secundario).
A diferencia de lo que afirman muchas guías, que 2>&1envía STDERR a donde se señala STDOUT. Si eso fuera cierto, todavía tendría el problema de sobrescritura.

Para obtener más información, consulte: http://mywiki.wooledge.org/BashGuide/InputAndOutput#File_Redirection

— the_velour_fog
fuente