Llevas tres lecciones escribiendo 2>/dev/null, | y > sin que nadie te haya explicado del todo qué son. Los has copiado porque funcionan. Esta lección desmonta la mecánica, y es probablemente la más importante del módulo: la redirección y las tuberías son el mecanismo con el que la filosofía Unix del Módulo 1 —programas pequeños que hacen una cosa bien y se componen— pasa de ser una frase bonita a ser algo que se teclea.

No es un tema donde baste con memorizar símbolos. Hay un puñado de casos —2>&1 >fichero frente a >fichero 2>&1, el código de salida de una tubería, sudo echo x > /etc/...— en los que la intuición engaña y todo el mundo se equivoca al menos una vez. Vamos a por ellos con el detalle suficiente para que no te pase.

1. Los tres flujos estándar y por qué existen
2. Verlos de verdad en /proc
3. Redirección de salida
4. Redirección de entrada
5. Redirección de error y el orden de evaluación
6. Los archivos especiales de /dev
7. Here-documents y here-strings
8. Tuberías: qué son realmente
9. El código de salida de una tubería
10. tee y el patrón | sudo tee
11. Buffering: cuando la salida no aparece
12. Componer una tubería paso a paso

Todo proceso en Linux nace con tres canales ya abiertos. No son una convención de Bash: los abre el sistema y están identificados por un número, el descriptor de archivo.

La pregunta interesante es por qué hay dos canales de salida si ambos van a la pantalla. La respuesta es la clave de todo el diseño: para poder separarlos cuando hace falta. Si el resultado y los errores viajaran por el mismo canal, no podrías guardar en un fichero solo lo útil, ni encadenar un programa con otro sin que los avisos contaminaran los datos.

> redirigió solo stdout al fichero. El error se quedó en la pantalla porque viaja por stderr. Esa separación es deliberada y es lo que permite que un find que recorre /etc con avisos de permiso denegado siga produciendo una lista limpia.

Como todo es un archivo, los descriptores se pueden mirar:

Los tres apuntan a /dev/pts/0, tu pseudoterminal. El 255 es de uso interno de Bash. Ahora fíjate en qué ocurre dentro de una redirección:

Los descriptores 1 y 2 ya no apuntan al terminal, sino al fichero. Redirigir no es una función del comando: es algo que Bash hace al proceso hijo antes de arrancarlo. Por eso funciona con cualquier programa, sin que el programa tenga que saber nada.

> trunca el fichero antes de ejecutar el comando, y lo crea si no existe. Eso significa que un > sobre un fichero con datos los destruye aunque el comando falle después.

noclobber convierte > en una operación que falla si el destino existe, y deja >| como la forma explícita de decir «sí, sobrescribe». Es un buen ajuste para una sesión de trabajo en producción; consúltalo con set -o | grep noclobber y desactívalo con set +o noclobber. La convención del curso —copia .bak-$(date +%F) antes de tocar nada— y noclobber se refuerzan mutuamente.

< fichero conecta stdin al fichero. Muchos comandos aceptan el nombre del fichero como argumento, así que la diferencia parece cosmética. No lo es:

Con <, el programa no conoce el nombre del fichero: solo recibe un flujo de bytes, y por eso no lo imprime. Es lo que quieres cuando el número va a alimentar otro cálculo. (26 líneas: la cabecera más los 25 registros.)

Aquí está el punto donde todo el mundo se equivoca. Bash procesa las redirecciones de izquierda a derecha, y 2>&1 no significa «une los dos flujos para siempre»: significa «copia el destino actual de 1 sobre 2». Es una fotografía del estado en ese instante.

Paso a paso: > /tmp/ok.txt apunta 1 al fichero; después 2>&1 copia ese destino sobre 2. Los dos acaban en el fichero. Correcto.

Paso a paso: 2>&1 copia el destino actual de 1, que todavía es el terminal, sobre 2; después > /tmp/mal.txt mueve 1 al fichero, pero 2 se quedó apuntando al terminal. Resultado: el error sale por pantalla y solo la salida normal va al fichero. Es exactamente lo contrario de lo que la mayoría cree estar escribiendo.

La regla práctica: 2>&1 va siempre al final. Y si no necesitas compatibilidad con otros shells, &> fichero es inequívoco y no admite el error.

Hay un uso legítimo del orden «equivocado»: comando 2>&1 >/dev/null | grep algo envía solo los errores a la tubería y descarta la salida normal. Es raro, pero cuando lo necesitas es la única forma.

2>/dev/null es el silenciador de ruido que ya usabas en 03-03. Úsalo con criterio: descarta todos los errores, incluidos los que sí querías ver. Si solo quieres ignorar los de permiso denegado, mejor filtrar que silenciar a ciegas.

/dev/stdout como ruta resulta útil cuando un comando exige un nombre de fichero y tú quieres su salida en la tubería, como tar -cf /dev/stdout. Y /dev/zero sirve para generar un fichero de tamaño conocido con el que probar una copia de seguridad:

Un here-document alimenta stdin con texto escrito en la propia línea de comandos, hasta un delimitador.

Con el delimitador entre comillas simples no se expande nada:

La regla: entrecomilla el delimitador salvo que quieras expansión deliberadamente. Es lo mismo que la regla de las comillas de 03-01, aplicada a bloques.

Un here-string <<< es la versión de una sola línea, y evita el echo ... | que se escribe por costumbre:

Una tubería no es un fichero temporal. Es un búfer en memoria del kernel —típicamente 64 KiB— con dos extremos: la salida estándar del proceso de la izquierda y la entrada estándar del de la derecha.

Y aquí está el punto que hay que entender: los dos procesos se ejecutan a la vez, no uno después del otro. El de la derecha empieza a consumir en cuanto hay datos. Si el búfer se llena porque el consumidor va más lento, el kernel duerme al productor hasta que haya sitio; si el búfer se vacía, duerme al consumidor. Esa sincronización automática es la razón de que puedas hacer cat fichero-de-50-GB | grep algo sin agotar la memoria.

Dos procesos simultáneos. grep escribe en el búfer, wc lee de él, y ninguno de los dos sabe que el otro existe: uno cree escribir en la pantalla y el otro cree leer del teclado. Eso es exactamente lo que hace posible componer programas que nunca fueron diseñados para trabajar juntos.

La tubería solo transporta stdout. Los errores del comando de la izquierda siguen yendo a la pantalla. Para meterlos también en la tubería, |& (equivalente a 2>&1 |):

Por defecto, $? devuelve el código del último comando de la tubería. Los anteriores se pierden, y eso oculta fallos:

cat falló, pero wc terminó bien y la tubería informa de éxito. Un procedimiento que compruebe $? daría por buena una operación que no leyó nada.

El array PIPESTATUS guarda el código de cada elemento:

Y set -o pipefail hace que la tubería devuelva el código del último comando que falló:

pipefail es imprescindible en scripts serios y lo verás integrado en set -euo pipefail en el Módulo 4. Aquí quédate con la idea: una tubería puede mentirte sobre su éxito, y sabes dos formas de que no lo haga.

tee lee de stdin y escribe a la vez en stdout y en uno o más ficheros. Bifurca el flujo.

Ves el recuento y además conservas las líneas en un fichero. Con -a añade en lugar de truncar, y con - como destino adicional puede duplicar a la pantalla en medio de una tubería, lo que la convierte en una excelente herramienta de depuración.

Parece contradictorio: hemos escrito sudo. La explicación está en el reparto de tareas. La redirección la ejecuta Bash, no sudo. Bash abre el fichero de destino antes de lanzar nada, y lo hace con los privilegios de operador, que no puede escribir en un fichero de root. El sudo afecta a echo, que es justo la parte que no necesitaba privilegios.

La solución es hacer que el proceso privilegiado sea el que escribe:

Ahora tee corre bajo sudo y es él quien abre el fichero. El > /dev/null final descarta la copia que tee manda a pantalla, que aquí no aporta nada. Y para añadir al final, | sudo tee -a, nunca >>, por el mismo motivo. Aplicado con la convención del curso:

El diff revela algo importante: hemos añadido una segunda clave log_nivel en lugar de corregir la existente. El fichero ahora tiene dos, y qué gana depende de cómo lo lea la aplicación. Este es el motivo por el que la convención exige el diff -u: no para admirar el cambio, sino para descubrir que no era el que querías. La corrección en sitio es trabajo de sed, en la lección siguiente.

Un programa escribe en un búfer y solo vuelca cuando se llena o cuando termina. La biblioteca de C aplica una regla que sorprende: si stdout es un terminal, el búfer es por líneas; si es una tubería o un fichero, es por bloques de 4 KiB.

Consecuencia práctica: tail -F acceso.log | grep 'ERROR 500' puede no mostrar nada durante minutos, no porque no haya errores, sino porque grep está acumulando 4 KiB antes de soltarlos. Parece que la tubería está rota y funciona perfectamente.

stdbuf -oL fuerza el búfer por líneas del comando siguiente. Alternativas: grep --line-buffered, awk con fflush(), sed -u. Recuerda que la convención del curso es tail -F y nunca -f en producción, porque -F sobrevive a la rotación del fichero.

El objetivo: las rutas con más errores 500 en acceso.log. Se construye por incrementos, verificando cada eslabón, igual que hacías con las regex.

De 412 líneas quedan 14. Ahora extraemos solo la ruta y agrupamos:

Nueve de catorce en /reservas, y los ms=30012 de la muestra rozan los 30 segundos, que es exactamente el timeout_consulta=30 de app.conf. La tubería no ha dado un dato: ha dado una hipótesis —las consultas a la base de datos agotan el tiempo límite— que encaja con el conexiones_activas=200 que vimos en 03-03 y con el max_conexiones=200 configurado. Eso es lo que se le lleva a Marta.

Repasa la composición: grep filtra, grep -oE extrae, sort agrupa lo igual, uniq -c cuenta, sort -rn ordena por frecuencia. Cinco programas que no se conocen entre sí, encadenados por un búfer del kernel. Ninguno sabe hacer el informe; juntos, sí.

• Escribir 2>&1 antes de la redirección de salida. Es el error clásico. Va al final, o usa &>.
• comando > fichero con el mismo fichero como entrada. sort datos.txt > datos.txt lo vacía: Bash trunca el destino antes de que sort lea. Usa sort -o datos.txt datos.txt o un temporal.
• sudo comando > /fichero/protegido. La redirección la hace tu shell. Usa | sudo tee.
• Fiarse de $? tras una tubería. Es el del último comando. Usa PIPESTATUS o pipefail.
• Silenciar con 2>/dev/null por reflejo. Estás descartando también los errores que necesitabas. Míralos primero.
• Creer que una tubería es secuencial. Los procesos corren a la vez; por eso funciona con ficheros enormes y por eso el buffering puede retrasar la salida.
• Olvidar entrecomillar el delimitador de un here-doc. Si el texto contiene $ o comillas, se expandirá.
• Consejo: intercala | tee /tmp/paso1.txt | en medio de una tubería larga para inspeccionar qué circula por ese punto sin romper la cadena.
• Consejo: command | cat desactiva la salida en color y en columnas de muchos programas, porque detectan que no escriben a un terminal. Si te falta el color, --color=always lo fuerza.

Ejercicio 1. Ejecuta un find sobre /etc como usuario normal, de modo que la lista de resultados quede en /tmp/hallazgos.txt y los errores de permiso en /tmp/fallos.txt, sin que nada salga por pantalla. Después cuenta cuántos errores hubo y explica por qué no habrías podido separarlos con &>.

Ejercicio 2. Añade la línea # revisado 2026-08-18 al final de /etc/tramontana/app.conf conservando la convención de copia previa y verificación posterior. Explica por qué sudo echo ... >> no sirve.

Ejercicio 3. Construye paso a paso una tubería que muestre las cinco direcciones IP con más peticiones en acceso.log, guardando a la vez el listado completo en /tmp/ips.txt. Verifica que el total de peticiones contadas coincide con las 412 líneas del fichero y explica qué harías si no coincidiera.

Solución 1.

Dos redirecciones independientes, cada flujo a su fichero, y la pantalla queda limpia. &> no sirve porque mezcla ambos flujos en un único destino, que es justo lo contrario de lo que pedía el enunciado. Los seis errores son directorios como /etc/ssl/private, legítimamente cerrados a un usuario normal: revisarlos en su propio fichero es mejor práctica que descartarlos con 2>/dev/null, porque un error inesperado ahí dentro sería una señal que no querrías perder.

Solución 2.

sudo echo '...' >> /etc/tramontana/app.conf falla porque la redirección la ejecuta tu shell antes de invocar a sudo, y tu shell corre como operador, que no tiene permiso de escritura sobre un fichero 640 propiedad de root. El sudo se aplicaría a echo, que no necesita privilegio alguno para imprimir texto. Con | sudo tee -a, el proceso que abre el fichero es tee, y ese sí corre como root. El cp -p conserva permisos y propietario en la copia, y ls -l confirma que el original sigue siendo 640 root:tramontana: escribir con tee bajo sudo no ha cambiado la propiedad del fichero, porque tee escribe en el fichero existente en vez de crearlo de nuevo.

Solución 3.

El primer comando es la verificación imprescindible: 412 coincidencias para 412 líneas, luego toda línea tiene exactamente un campo ip=. Si hubiera salido menos, habría líneas con otro formato que se estarían quedando fuera del informe en silencio; si más, alguna línea con dos IPs y un recuento inflado. En ambos casos habría que examinar las líneas discordantes con grep -vc 'ip=' antes de seguir, porque un informe construido sobre un supuesto no verificado es un informe que se puede desmentir.

tee bifurca: el fichero recibe el listado completo y head -5 se queda con el podio. La suma final con awk —que estudiarás en la lección siguiente— cierra el círculo: 412 de nuevo, así que ninguna petición se ha perdido ni duplicado por el camino. Y hay un hallazgo: 10.0.2.77 concentra 138 peticiones, un tercio del total y casi el 50 % más que la siguiente. Merece investigación.

Has pasado de copiar símbolos a entender por dónde circula cada byte.

• Conoces los tres flujos estándar —stdin 0, stdout 1, stderr 2—, sabes por qué existen dos canales de salida, y los has visto de verdad en /proc/<pid>/fd.
• Manejas >, >>, noclobber con >|, y <, sabiendo que con < el programa no conoce el nombre del fichero.
• Tienes resuelto el error clásico: 2>&1 copia el destino actual de 1, se evalúa de izquierda a derecha y por eso va al final; &> es el atajo inequívoco.
• Usas /dev/null, /dev/zero y /dev/stdout con criterio, sabiendo que silenciar errores a ciegas oculta los que sí importaban.
• Escribes here-documents y here-strings, y entrecomillas el delimitador cuando no quieres expansión.
• Sabes que una tubería es un búfer del kernel entre dos procesos que corren a la vez, que solo transporta stdout, y que |& incluye los errores.
• No te fías del código de salida de una tubería: conoces PIPESTATUS y set -o pipefail.
• Aplicas | sudo tee para escribir en ficheros protegidos, y sabes explicar por qué sudo echo x > /etc/... falla: la redirección la hace tu shell, no sudo.
• Reconoces el buffering por bloques cuando un log no aparece en tiempo real y lo corriges con stdbuf -oL.
• Y has compuesto una tubería incrementalmente hasta convertir 412 líneas de log en una hipótesis de diagnóstico defendible.

En esas tuberías han aparecido sort, uniq -c y hasta un awk sin explicar. Es la deuda que salda la siguiente lección. Procesamiento de Texto: cut, sort, uniq, sed y awk cierra el círculo que abrió la filosofía Unix del Módulo 1: el texto plano como interfaz universal entre programas. Aprenderás a recortar campos, ordenar por la columna que quieras, contar apariciones, transformar con sed sin destrozar el original, y agrupar y sumar con awk hasta sustituir media tubería por una sola orden. Al terminarla podrás entregarle a Marta el informe de facturación mensual de reservas.csv y el top de rutas con errores de acceso.log sin escribir una línea de código.