stdin, stdout y stderr son tres flujos de datos creados al iniciar un comando de Linux. Puede usarlos para saber si sus scripts se están canalizando o redirigiendo. Le mostramos cómo.
Streams Unir dos puntos
Tan pronto como Cuando comienzas a aprender sobre Linux y sistemas operativos tipo Unix, te encontrarás con los términos stdin, stdout y stederr. Estas son tres secuencias estándar que se establecen cuando se ejecuta un comando de Linux. En informática, un flujo es algo que puede transferir datos. En el caso de estas corrientes, esos datos son texto.
Las corrientes de datos, como las corrientes de agua, tienen dos extremos. Tienen una fuente y un flujo de salida. Cualquiera que sea el comando de Linux que esté utilizando, proporciona un extremo de cada transmisión. El otro extremo está determinado por el shell que lanzó el comando. Ese extremo estará conectado a la ventana del terminal, conectado a una tubería o redirigido a un archivo u otro comando, de acuerdo con la línea de comando que lanzó el comando.
Las transmisiones estándar de Linux
En Linux, stdin es la secuencia de entrada estándar. Esto acepta texto como su entrada. La salida de texto del comando al shell se entrega a través de la secuencia stdout (salida estándar). Los mensajes de error del comando se envían a través de la secuencia stderr (error estándar).
Para que pueda ver que hay dos secuencias de salida, stdout y stderr, y una secuencia de entrada, stdin. Debido a que los mensajes de error y la salida normal tienen cada uno su propio conducto para llevarlos a la ventana del terminal, se pueden manejar independientemente uno del otro.
Las secuencias se manejan como archivos
Secuencias en Linux —Como casi todo lo demás— se tratan como si fueran archivos. Puede leer texto de un archivo y puede escribir texto en un archivo. Ambas acciones implican un flujo de datos. Por lo tanto, el concepto de manejar una secuencia de datos como un archivo no es tan difícil.
A cada archivo asociado con un proceso se le asigna un número único para identificarlo. Esto se conoce como el descriptor de archivo. Cada vez que se requiere realizar una acción en un archivo, el descriptor de archivo se usa para identificar el archivo.
Estos valores siempre se usan para stdin, stdout y stderr:
- < li> 0: stdin
- 1: stdout
- 2: stderr
Reacción a tuberías y redireccionamientos
Para facilitar Introducción de alguien a un tema, una técnica común es enseñar una versión simplificada del tema. Por ejemplo, con la gramática, se nos dice que la regla es "I antes de E, excepto después de C." Pero en realidad, hay más excepciones a esta regla que casos que la obedecen.
De manera similar, cuando se habla de stdin, stdout y stderr, es conveniente trotar el axioma aceptado de que un proceso no sabe ni le importa dónde terminan sus tres flujos estándar. ¿Debería importarle un proceso si su salida se dirige al terminal o se redirige a un archivo? ¿Puede incluso saber si su entrada proviene del teclado o se está canalizando desde otro proceso?
En realidad, un proceso sí lo sabe, o al menos puede averiguarlo, si decide verificarlo. y puede cambiar su comportamiento en consecuencia si el autor del software decide agregar esa funcionalidad.
Podemos ver este cambio en el comportamiento muy fácilmente. Pruebe estos dos comandos:
ls
ls | cat
El comando ls se comporta de manera diferente si su salida (stdout) se canaliza a otro comando. Es ls que cambia a una salida de una sola columna, no es una conversión realizada por cat. Y ls hace lo mismo si su salida se redirige:
ls > capture.txt
cat capture.txt
Redirigiendo stdout y stderr
Hay una ventaja de recibir mensajes de error en una transmisión dedicada. Significa que podemos redirigir la salida de un comando (stdout) a un archivo y seguir viendo mensajes de error (stderr) en la ventana del terminal. Puede reaccionar a los errores si es necesario, ya que ocurren. También evita que los mensajes de error contaminen el archivo al que se ha redirigido stdout.
Escriba el siguiente texto en un editor y guárdelo en un archivo llamado error.sh.
[ PRE] #! / Bin / bash echo "A punto de intentar acceder a un archivo que no existe" cat bad-filename.txt
Haga que el script sea ejecutable con este comando:
chmod + x error.sh
La primera línea del script hace eco del texto en la ventana del terminal, a través de la salida estándar corriente. La segunda línea intenta acceder a un archivo que no existe. Esto generará un mensaje de error que se envía a través de stderr.
Ejecute el script con este comando:
./ error.sh
Podemos ver que ambas secuencias de salida, stdout y stderr, se han mostrado en las ventanas del terminal.
Intentemos redirigir la salida a un archivo:
./ error.sh > capture.txt
El mensaje de error que se entrega a través de stderr todavía se envía a la ventana del terminal. Podemos verificar el contenido del archivo para ver si la salida stdout fue al archivo.
cat capture.txt
La salida desde stdin fue redirigido al archivo como se esperaba.
El > El símbolo de redirección funciona con stdout por defecto. Puede usar uno de los descriptores numéricos de archivos para indicar qué flujo de salida estándar desea redirigir.
Para redirigir explícitamente stdout, use esta instrucción de redirección:
1 >
Para redirigir explícitamente stderr, use esta instrucción de redirección:
2 >
Intentemos nuestra prueba nuevamente, y esta vez usaremos 2 & gt ;:
./ error.sh 2 > capture.txt
El mensaje de error se redirige y el mensaje stdoutecho se envía a la ventana del terminal:
Vamos a vea qué hay en el archivo capture.txt.
cat capture.txt
El mensaje stderr está en capture.txt como se esperaba.
Redirigiendo Stdout y stderr
Sin duda, si podemos redirigir stdout o stderr a un archivo independientemente uno del otro, deberíamos poder para redirigirlos a ambos al mismo tiempo, a dos archivos diferentes?
Sí, podemos. Este comando dirigirá stdout a un archivo llamado capture.txt y stderr a un archivo llamado error.txt.
./ error.sh 1 > capture.txt 2 > error.txt
Debido a que ambas secuencias de salida –salida estándar y error estándar– se redirigen a los archivos, no hay salida visible en la ventana de terminal. Regresamos a la línea de comandos como si no hubiera ocurrido nada.
Verifiquemos el contenido de cada archivo:
captura de gato. txt
error de gato.txt
Redirigiendo stdout y stderr al mismo archivo
Eso está bien, nosotros ' Tengo cada una de las secuencias de salida estándar yendo a su propio archivo dedicado. La única otra combinación que podemos hacer es enviar stdout y stderr al mismo archivo.
Podemos lograr esto con el siguiente comando:
./ error.sh > capture.txt 2 & > 1
Vamos a desglosar eso.
- ./error.sh: Inicia el archivo de script error.sh.
- > capture.txt: Redirige la secuencia stdout al archivo capture.txt. > es la abreviatura de 1 & gt ;.
- 2 > & 1: utiliza el & > instrucción de redireccionamiento. Esta instrucción le permite decirle al shell que haga que una secuencia llegue al mismo destino que otra secuencia. En este caso, estamos diciendo "redirigir el flujo 2, stderr, al mismo destino al que se está redirigiendo el flujo 1, stdout".
No hay salida visible. Eso es alentador.
Revisemos el archivo capture.txt y veamos qué contiene.
cat capture.txt
Tanto las secuencias stdout como stderr se han redirigido a un único archivo de destino.
Para que la salida de una secuencia se redirija y se descarte silenciosamente, dirija la salida a / dev / null.
Detección de redireccionamiento dentro de un script
Discutimos cómo un comando puede detectar si alguno de los flujos se redirige, y puede elegir alterar su comportamiento en consecuencia. ¿Podemos lograr esto en nuestros propios guiones? Si podemos. Y es una técnica muy fácil de entender y emplear.
Escriba el siguiente texto en un editor y guárdelo como input.sh.
#! / Bin / bash si [-t 0]; luego echo stdin proveniente del teclado, de lo contrario echo stdin proveniente de una tubería o un archivo fi
Use el siguiente comando para hacerlo ejecutable:
chmod + x input.sh
La parte inteligente es la prueba entre corchetes. La opción -t (terminal) devuelve verdadero (0) si el archivo asociado con el descriptor de archivo termina en la ventana de terminal. Hemos utilizado el descriptor de archivo 0 como argumento para la prueba, que representa stdin.
Si stdin está conectado a una ventana de terminal, la prueba será verdadera. Si stdin está conectado a un archivo o una tubería, la prueba fallará.
Podemos usar cualquier archivo de texto conveniente para generar entradas para el script. Aquí estamos usando uno llamado dummy.txt.
./ input.sh < dummy.txt
El resultado muestra que el script reconoce que la entrada no proviene de un teclado, sino de un archivo. Si lo desea, puede variar el comportamiento de su script en consecuencia.
Eso fue con una redirección de archivo, intentemos con una tubería.
[ PRE] cat dummy.txt | ./input.sh[/PREfont>
El script reconoce que su entrada se está canalizando hacia él. O, más precisamente, reconoce una vez más que la transmisión estándar no está conectada a una ventana de terminal.
Ejecutemos el script sin canalizaciones ni redireccionamientos.
./ input.sh
La secuencia stdin está conectada a la ventana de terminal, y el script informa esto en consecuencia.
Para verifique lo mismo con la secuencia de salida, necesitamos un nuevo script. Escriba lo siguiente en un editor y guárdelo como output.sh.
#! / Bin / bash if [-t 1]; entonces echo stdout va a la ventana de terminal, de lo contrario echo stdout se redirige o canaliza fi
Use el siguiente comando para hacerlo ejecutable:
chmod + x input.sh
El único cambio significativo en este script está en la prueba entre corchetes. Estamos usando el dígito 1 para representar el descriptor de archivo para stdout.
Probémoslo. Canalizaremos la salida a través de cat.
./ output | cat
El script reconoce que su salida no va directamente a una ventana de terminal.
También podemos probar el script redirigiendo la salida a un archivo.
./ output.sh > capture.txt
No hay salida a la ventana de terminal, regresamos silenciosamente al símbolo del sistema. Como era de esperar.
Podemos mirar dentro del archivo capture.txt para ver qué fue capturado. Utilice el siguiente comando para hacerlo.
cat capture.sh
Nuevamente, la prueba simple en nuestro script detecta que la secuencia estándar no se envía directamente a una ventana de terminal.
Si ejecutamos el script sin ninguna canalización o redirección, debería detectar que stdout se entrega directamente a la ventana de terminal.
[ PRE] ./ output.sh
Y eso es exactamente lo que vemos.
Flujos de conciencia
Saber cómo saber si sus scripts están conectados a la ventana de terminal, a una tubería, o si están siendo redirigidos, le permite ajustar su comportamiento en consecuencia.
El registro y la salida de diagnóstico pueden ser más o menos menos detallado, dependiendo de si va a la pantalla o a un archivo. Los mensajes de error se pueden registrar en un archivo diferente al resultado normal del programa.
Como suele ser el caso, más conocimiento trae más opciones.
Fuente: How to Geek
Comentarios
Publicar un comentario