Redirigir la entrada y la salida

1. Qué es redirigir

Redirigir es conectar uno de los canales estándar de un comando a un archivo, en lugar de la terminal. La conexión la hace la shell antes de ejecutar el comando, que no se entera del cambio.

Todos los operadores del tema responden a un mismo esquema: un número de canal, que a veces se omite; un signo que indica la dirección; y un destino.

El signo apunta en el sentido en que viajan los datos. Trabajamos en un taller dentro del directorio de práctica:

$ cd ~/practica
$ mkdir taller
$ cd taller

2. > : la salida a un archivo

El operador más usado envía a un archivo lo que el comando iba a escribir en la pantalla:

$ ls -l .. > listado.txt
$ cat listado.txt
total 32
drwxrwxr-x 2 ana ana  4096 oct 12 10:40 fotos
-rw-rw-r-- 1 ana ana 12813 oct 12 10:41 informe.txt
-rw-rw-r-- 1 ana ana    18 oct 12 10:32 notas.txt
drwxrwxr-x 2 ana ana  4096 oct 12 19:30 taller
-rw-rw-r-- 1 ana ana    70 oct 12 13:20 tareas.txt

El primer comando no mostró nada: todo lo que ls escribió fue a parar al archivo. Si listado.txt no existía, se creó; el nombre de la derecha es siempre un archivo, nunca un comando.

Así se conserva cualquier resultado: un listado, la salida de id, la lista de paquetes instalados, el resultado de una búsqueda con find. Lo que antes pasaba por la pantalla y se perdía, queda guardado y se puede revisar, comparar o enviar.

Lo usamos desde el tema 2, sin explicarlo, para crear archivos: echo "Mi primer archivo" > notas.txt. Ahora se entiende qué ocurría. echo no sabe crear archivos; escribe en su salida, y la shell había conectado esa salida a un archivo.

3. > vacía el archivo antes de empezar

El operador tiene un comportamiento que hay que conocer antes de usarlo en serio:

$ echo "uno" > prueba.txt
$ echo "dos" > prueba.txt
$ cat prueba.txt
dos

El momento en que ocurre es decisivo. Según el orden que vimos en el tema 22, la shell abre los archivos antes de lanzar el comando. Dos experimentos lo muestran. El primero es inofensivo:

$ ls > contenido.txt
$ cat contenido.txt
contenido.txt
listado.txt
prueba.txt

contenido.txt figura dentro de su propio listado. Cuando ls empezó a trabajar, el archivo ya había sido creado por la shell.

El segundo experimento es la trampa clásica. Se quiere ordenar un archivo y guardar el resultado en el mismo archivo. Lo probamos sobre una copia:

$ cp ../tareas.txt .
$ sort tareas.txt > tareas.txt      # «ordenar el archivo en su lugar»
$ wc -c tareas.txt
0 tareas.txt

El archivo quedó vacío. La shell lo truncó para preparar la salida, y cuando sort lo abrió para leerlo ya no había nada que ordenar. No hubo ningún mensaje de error, porque desde el punto de vista de cada parte todo salió bien.

$ cp ../tareas.txt .                # recuperar la copia
$ sort tareas.txt > ordenadas.txt
$ cat ordenadas.txt
Comprar pan
Estudiar vim
Llamar a Luis
Pagar la luz
Regar las plantas

Para quien quiera una red de protección, Bash tiene una opción que impide que > sobrescriba archivos existentes:

$ set -o noclobber
$ echo "tres" > prueba.txt
bash: prueba.txt: cannot overwrite existing file
$ echo "tres" >| prueba.txt        # >| : sobrescribir de todos modos
$ set +o noclobber                  # volver al comportamiento normal

4. >> : añadir al final

Con el signo doble, la salida se agrega al final del archivo, y lo que había se conserva:

$ echo "Inicio de la tarea" >> registro.log
$ echo "Fin de la tarea" >> registro.log
$ cat registro.log
Inicio de la tarea
Fin de la tarea

Es el operador de los registros, y el que usamos en el tema 12 para alimentar un archivo mientras tail -f lo seguía. También es la forma habitual de añadir una línea a un archivo de configuración sin abrir un editor, como un alias en ~/.bash_aliases.

Ante la duda entre los dos, >> es el que no destruye. El error contrario —usar > donde se quería añadir, sobre un archivo de configuración— es de los más frecuentes y de los más caros: deja el archivo con una sola línea.

5. 2> : los errores a un archivo

Los dos operadores anteriores actúan sobre el canal 1. Para el canal de errores se antepone su número, sin espacio entre el 2 y el signo:

$ ls ../notas.txt nada.txt 2> errores.txt
../notas.txt
$ cat errores.txt
ls: cannot access 'nada.txt': No such file or directory

El resultado siguió llegando a la pantalla, y el mensaje de error quedó en el archivo. Los dos canales se pueden redirigir a la vez, cada uno a su destino, que es la situación del diagrama:

$ find /etc -name "*.conf" > conf.txt 2> sin-permiso.txt
$ wc -l conf.txt sin-permiso.txt
  312 conf.txt
    4 sin-permiso.txt
  316 total

La búsqueda no escribió nada en la pantalla. Quedaron dos archivos: uno con los 312 resultados, limpio, listo para procesar; y otro con los cuatro directorios que find no pudo revisar, para mirarlos después. Es la separación entre datos y comentarios del tema anterior, llevada al disco.

El número debe ir pegado al signo. Con un espacio, 2 > archivo, la shell entiende otra cosa: un argumento 2 para el comando, y una redirección común de la salida.

6. Juntar los dos canales: 2>&1

A veces se quiere lo contrario de separar: todo lo que el comando diga, resultados y errores, en un solo archivo y en el orden en que ocurrió. Es lo habitual al guardar el registro de una tarea larga.

El intento obvio, > todo.txt 2> todo.txt, no funciona bien: la shell abre el archivo dos veces, de manera independiente, y lo que se escribe por un canal pisa lo que se escribe por el otro. Hace falta decir que los dos canales comparten un mismo destino:

comando > todo.txt 2>&1
                   │││
                   ││└─ …del canal 1
                   │└─ &: «lo que sigue es un canal, no un archivo»: el destino actual…
                   └─ el canal 2 pasa a apuntar al…

Se lee: «el canal 2, envíalo al mismo lugar adonde está yendo el canal 1». El signo & es lo que distingue un número de canal de un nombre de archivo: 2>1, sin él, enviaría los errores a un archivo llamado 1.

$ ls ../notas.txt nada.txt > todo.txt 2>&1
$ cat todo.txt
ls: cannot access 'nada.txt': No such file or directory
../notas.txt

Bash tiene una abreviatura para esta combinación, más corta y sin la dificultad de la sección siguiente:

La forma abreviada es propia de Bash. La larga funciona en todas las shells, y es la que encontrarás en scripts pensados para cualquier sistema; por eso conviene saber leer las dos.

7. El orden importa

La forma larga tiene una exigencia que desconcierta: 2>&1 debe escribirse después de la redirección de la salida. Al revés, no hace lo esperado:

$ ls ../notas.txt nada.txt 2>&1 > todo.txt
ls: cannot access 'nada.txt': No such file or directory
$ cat todo.txt
../notas.txt

El error apareció en la pantalla, y el archivo solo recibió el resultado. La explicación está en dos hechos. La shell procesa las redirecciones de izquierda a derecha. Y 2>&1 no crea un vínculo permanente entre los canales: copia el destino que el canal 1 tiene en ese instante.

En el segundo caso, cuando se copia el destino del canal 1, este todavía apunta a la pantalla. El cambio posterior del canal 1 ya no afecta al 2.

La regla práctica: primero se dice adónde va la salida, y después que los errores la acompañan. O se usa &>, que no deja lugar a equivocarse.

8. Descartar: /dev/null

Cuando lo que un comando escribe no interesa, el destino es el archivo de dispositivo que conocimos en el tema 8: /dev/null acepta todo lo que se le envía y no guarda nada.

El tercer caso parece absurdo: ¿para qué ejecutar un comando y tirar todo lo que dice? Porque queda la cuarta vía del tema anterior, el código de salida. Muchas veces la pregunta no es «¿qué encontraste?» sino «¿encontraste algo?»:

$ grep "pan" tareas.txt &> /dev/null
$ echo $?
0                                   # 0: la palabra está en el archivo

Es la forma en que los scripts hacen preguntas a los comandos; la aprovechamos en el tema 25.

9. < : la entrada desde un archivo

El signo invertido conecta un archivo al canal 0: el comando recibe por su entrada el contenido del archivo, como si alguien lo estuviera tecleando.

$ tr 'a-z' 'A-Z' < ../notas.txt
MI PRIMER ARCHIVO
$ sort < tareas.txt > ordenadas.txt        # la entrada de un archivo, la salida a otro

tr, de translate, reemplaza unos caracteres por otros; aquí, las minúsculas por mayúsculas. Lo vemos en el tema 26. Sirve de ejemplo porque es uno de los pocos comandos que solo lee de su entrada: no acepta un nombre de archivo, de modo que < es la manera de darle uno.

Con la mayoría de los comandos, < es opcional, porque aceptan el archivo como argumento. Las diferencias las vimos en el tema anterior, con wc. Resumidas:

La línea sort < tareas.txt > ordenadas.txt se lee de izquierda a derecha como un recorrido: los datos salen del primer archivo, pasan por sort y llegan al segundo.

10. Documentos en línea: <<

Hay una forma de darle a un comando varias líneas de entrada sin crear un archivo: escribirlas a continuación, en la misma línea de comandos o en el mismo script.

Un documento en línea, en inglés here document, es un bloque de texto que la shell entrega a la entrada estándar de un comando. Empieza con << seguido de una palabra, y termina en la primera línea que contenga solo esa palabra.

$ cat > config.txt << FIN
> usuario=$USER
> directorio=$HOME
> FIN
$ cat config.txt
usuario=ana
directorio=/home/ana

El indicador > al comienzo de cada renglón lo pone la shell, como vimos en el tema 5: avisa que espera el resto. La palabra FIN es un delimitador que se elige libremente; por costumbre se usa EOF. La línea de cierre debe contener esa palabra y nada más, sin espacios antes ni después.

La primera línea combina dos redirecciones: la entrada de cat es el bloque de texto, y su salida va a config.txt. Es la manera corriente de crear un archivo de varias líneas desde un script, y la que verás en muchas guías de instalación.

Dentro del bloque, la shell reemplazó las variables, como entre comillas dobles. Poniendo el delimitador entre comillas se desactiva, y el texto llega literal:

11. Cadenas en línea: <<<

Para una sola línea hay una forma todavía más breve, con tres signos. El texto que sigue se entrega a la entrada del comando:

$ tr 'a-z' 'A-Z' <<< "hola mundo"
HOLA MUNDO
$ wc -w <<< "uno dos tres"
3

Reemplaza a una construcción muy común, echo "texto" | comando, con el mismo resultado. Es propia de Bash, y resulta cómoda para probar un filtro con un dato suelto, que es justo como la usaremos en el bloque 6.

12. Dónde se escribe una redirección

Las redirecciones no son argumentos. La shell las reconoce, las aplica y las quita de la línea antes de pasarla al comando. De eso se siguen varias reglas de escritura.

Pueden ir en cualquier lugar de la línea. Las tres formas siguientes son idénticas, y en las tres ls recibe los mismos dos argumentos:

ls -l .. > listado.txt
ls -l > listado.txt ..
> listado.txt ls -l ..

Por legibilidad se escriben al final, y esa es la costumbre que conviene seguir.

El espacio después del signo es opcional; antes del número, obligatorio. >archivo y > archivo son lo mismo. En cambio 2> no admite un espacio en el medio, y debe estar separado de lo que tenga delante.

Una redirección sin comando también vale. Como el archivo lo crea o lo vacía la shell, no hace falta ningún comando para eso:

$ > vacio.txt                       # crea el archivo, o lo vacía si existía
$ ls -l vacio.txt
-rw-rw-r-- 1 ana ana 0 oct 12 19:52 vacio.txt

Es el modo habitual de vaciar un registro que creció demasiado sin borrarlo, cosa que importa cuando un servicio lo tiene abierto, por lo que explicamos en el tema 14.

Cada canal va a un solo destino. Con comando > a.txt > b.txt se crean los dos archivos y la salida va solo al último; el primero queda vacío. Para enviar la misma salida a dos lugares hace falta un comando, tee, que vemos en el tema siguiente.

13. Redirecciones y permisos

Como el archivo lo abre la shell, lo abre con tu identidad y con los permisos que estudiamos en el bloque 4:

$ echo "prueba" > /etc/prueba.conf
bash: /etc/prueba.conf: Permission denied

El mensaje empieza con bash, no con echo: quien no pudo abrir el archivo fue la shell, y echo no llegó a ejecutarse. Es lo que encontramos en el tema 19, y la razón por la que sudo delante no lo arregla. La solución que vimos allí, | sudo tee, consiste en que el archivo lo abra un programa que sí corre con privilegios.

Una observación sobre lo que se crea: los archivos nacidos de una redirección reciben los permisos que resultan de la máscara, rw-rw-r-- en Ubuntu. Si lo que se guarda es delicado, conviene fijar antes la máscara o ajustar después los permisos, como vimos en el tema 18.

14. Todos los operadores

La octava fila es nueva, y tiene un uso preciso. Es lo que hace un script para escribir un mensaje de error por el canal que corresponde: echo "No se encontró el archivo" >&2. Así, quien use ese script podrá separar sus resultados de sus errores, como hicimos aquí con los de ls y find.

Y las recetas de todos los días:

Desarmamos el taller:

$ cd ~/practica
$ rm -r taller
$ ls
fotos  informe.txt  notas.txt  tareas.txt

Con las redirecciones, los canales de un comando llegan a los archivos. En el tema 24 damos el paso que falta: conectar la salida de un comando directamente con la entrada de otro, sin archivos de por medio.

15. Resumen

• Redirigir es conectar un canal de un comando a un archivo. Lo hace la shell, antes de ejecutar el comando.
• > envía la salida a un archivo. Si el archivo existe, lo vacía primero, sin preguntar.
• Como la shell prepara el archivo antes de lanzar el comando, usar el mismo archivo como entrada y como salida lo deja vacío.
• >> añade al final del archivo, conservando lo que había.
• 2> y 2>> hacen lo mismo con el canal de errores. El número va pegado al signo.
• 2>&1 envía los errores al destino actual de la salida. &> es la abreviatura de Bash para enviar los dos canales a un archivo.
• Las redirecciones se procesan de izquierda a derecha: > archivo 2>&1 junta los canales; en el orden inverso, los errores siguen yendo a la pantalla.
• /dev/null descarta lo que recibe. 2> /dev/null quita los errores; &> /dev/null, todo, y queda el código de salida.
• < conecta un archivo a la entrada del comando.
• << PALABRA entrega como entrada las líneas siguientes, hasta el delimitador; <<<, un texto de una línea.
• Las redirecciones no son argumentos: pueden ir en cualquier lugar de la línea, y el comando no las recibe.
• El archivo de una redirección se abre con la identidad y los permisos del usuario, no con los del comando.

16. Preguntas de repaso

Intenta responder cada una antes de abrir la respuesta.

Para practicar

1. Guarda en un archivo la salida de id, en otro la de ls -la ~, y añade al primero la de date. Revisa los dos con cat.
2. Ejecuta dos veces date > fecha.txt y dos veces date >> fechas.txt. ¿Cuántas líneas tiene cada archivo?
3. Reproduce la trampa de la sección 3 con una copia de un archivo, y luego ordénala correctamente de dos maneras: con un archivo intermedio y con sort -o.
4. Ejecuta find /var -name "*.log" guardando los resultados en un archivo y los errores en otro. Cuenta las líneas de cada uno.
5. Repite la búsqueda enviando todo a un solo archivo, primero con > archivo 2>&1 y luego con &>. Compara los dos archivos con wc -l.
6. Prueba ls nada.txt 2>&1 > salida.txt y ls nada.txt > salida.txt 2>&1. ¿En cuál queda el error dentro del archivo?
7. Activa noclobber, intenta sobrescribir un archivo, fuérzalo con >|, y desactiva la opción.
8. Crea con un documento en línea un archivo de cinco líneas que incluya $HOME y $(date). Repite con el delimitador entre comillas simples y compara.
9. Usa tr 'a-z' 'A-Z' con < sobre tareas.txt, y con <<< sobre un texto cualquiera. Guarda el primer resultado en un archivo.
10. Crea un archivo con contenido, vacíalo con > archivo y comprueba con ls -li, antes y después, que el inodo es el mismo.