Estoy leyendo un ejemplo de script de shell bash:
#!/bin/bash
# This script makes a backup of my home directory.
cd /home
# This creates the archive
tar cf /var/tmp/home_franky.tar franky > /dev/null 2>&1
# First remove the old bzip2 file. Redirect errors because this generates some if the archive
# does not exist. Then create a new compressed file.
rm /var/tmp/home_franky.tar.bz2 2> /dev/null
bzip2 /var/tmp/home_franky.tar
# Copy the file to another host - we have ssh keys for making this work without intervention.
scp /var/tmp/home_franky.tar.bz2 bordeaux:/opt/backup/franky > /dev/null 2>&1
# Create a timestamp in a logfile.
date >> /home/franky/log/home_backup.log
echo backup succeeded >> /home/franky/log/home_backup.log
Estoy tratando de entender el uso de "/ dev / null 2> & 1" aquí. Al principio, pensé que este script usa / dev / null para ignorar con gracia los errores, sin causar que el script se bloquee (algo así como intentar capturar el manejo de excepciones en lenguajes de programación). Porque no veo cómo el uso de tar para comprimir un directorio en un archivo tar podría causar algún tipo de error.
bash-script
null
JohnMerlino
fuente
fuente
/dev/null
no evitará fallas, pero limpiará las secuencias de salida stdout y stderr.tar
podría causar errores de varias maneras. Es posible que no tenga acceso de escritura, que el archivo ya exista, etc.tar
no está en su $ PATH, porquetar
se bloqueó (nunca se sabe), porque no queda espacio en el dispositivo, porque latar
versión cambió y ahora requiere una sintaxis diferente, porque el disco causó un error de E / S. Estoy seguro de que puedes encontrar más.Respuestas:
No, esto no evitará que el script se bloquee. Si se produce algún error en el
tar
proceso (por ejemplo: permiso denegado, ningún archivo o directorio, ...), el script seguirá fallando.Debido a que el uso
> /dev/null 2>&1
redirigirá toda la salida de su comando (ambosstdout
ystderr
) a/dev/null
, lo que significa que no se imprimen salidas en el terminal.Por defecto:
En el script, usas
> /dev/null
causar:Y luego
2>&1
causando:fuente
> /dev/null 2>&1
, este comando da como resultadostderr ==> stdout
, ¿así que stderr todavía se imprime en stdout?fd
?CMD > /dev/null 2>&1
peroCMD 2>&1 > /dev/null
todavía me da STDERR?2>& 1
en ejemplos de código para enfatizar que el número y el ampersand se consideran parte del operador de redireccionamiento. Es común que la redirección a un archivo tenga un espacio entre>
y/path/to/file
, la redirección a un descriptor de archivo es esencialmente lo mismo.(tenga en cuenta que agregué la redirección antes
/dev/null
en su pregunta).Lo anterior redirigiría el
STDOUT
ySTDERR
hacia/dev/null
. Funciona fusionando elSTDERR
en elSTDOUT
. (Esencialmente, toda la salida del comando se redirigiría al dispositivo nulo ).No es como un
try/catch
o nada. Simplemente silencia cualquier tipo de salida (incluido el error) del comando.Podría provocar errores por varias razones, que incluyen:
fuente
Cuando ejecuta CMD> / dev / null 2> & 1
STDOUT redirige a / dev / null, y luego STDERR redirige a LA DIRECCIÓN de STDOUT, que se ha establecido en / dev / null, por lo tanto, STDOUT y STDERR apuntan a / dev / null
Opuestamente, cuando ejecuta CMD 2> & 1> / dev / null
STDERR redirige a LA DIRECCIÓN de STDOUT (descriptor de archivo 1 en ese momento, o / proc / self / fd / 1), y luego STDOUT redirige a / dev / null, ¡pero STDERR sigue redirigiendo a fd1! Como resultado, la salida normal de STDOUT se descarta, pero los errores que provienen de STDERR todavía se escriben en la consola.
fuente
Redirección de E / S de Bash
La idea principal para aclarar las cosas es esta:
Entonces este código:
redirige
stderr
astdout
first (2>&1
) y luego envíastdout
(incluido el redirigidostderr
) afilename
(> filename
). Aquí está la explicación de ABSG (Capítulo 20) .Este código:
redirecciona
stderr
ystdout
a/dev/null
... lo que significa a ninguna parte . Las cosas enviadas a/dev/null
no se guardan, almacenan en caché ni se recuerdan de ninguna manera.Simplemente se envían a " ninguna parte " y se olvidan. Esta es una forma de ejecutar programas y asegurarse de que NO produzcan resultados y que nunca se verán en la línea de comandos o en un archivo de registro.
Veo este tipo de preguntas bastante ... principalmente porque he tenido que buscarlo yo mismo ya que no he estado codificando en años. Aquí hay información útil de ABSG:
"La redirección simplemente significa capturar la salida de un archivo, comando, programa o script y enviarlo como entrada a otro archivo, comando, programa o script".
ABSG: Guía avanzada de secuencias de comandos Bash: el enlace del Capítulo 20 anterior es un enlace a la página de redirección de E / S del documento de código abierto tldp.org llamada Guía avanzada de secuencias de comandos Bash de Mendel Cooper. Está catalogado como "Una exploración en profundidad del arte de las secuencias de comandos de shell" y estoy totalmente de acuerdo. Es un recurso excelente y tiene toneladas de respuestas a todo tipo de situaciones locas.
Otros recursos valiosos: Hay muchos recursos valiosos en la sección actual / mantenida (en varios formatos útiles como html, pdf, texto, etc.) en la página de Guías del proyecto de documentación de Linux . Aquí hay algunos que he encontrado útiles:
fuente
filename
, luego el error estándar se redirige a donde sea que vaya la salida estándar (afilename
). Si fuera al revés, el error estándar terminaría en el terminal mientras que solo se redirige la salida estándarfilename
. También, encommand >file1 2>file2
,file2
que no se creará sifile1
no pudo ser creado (no importa sifile1
yfile2
en realidad eran totalmente diferentes nombres de ruta).