Módulo 3: Tuberías, redirección y composición

1. Introducción: comandos que se conectan entre sí

Siguiente →

Descripción

Hasta ahora aprendiste comandos. Cada uno resuelve una pregunta puntual: ls te dice qué hay aquí, grep te dice dónde está esa palabra, find te dice dónde vive ese archivo. Son herramientas completas por sí solas, y ya te sacaron de apuros reales en los dos módulos anteriores.

Este módulo te enseña algo distinto, y es el punto exacto donde la terminal deja de ser una lista de comandos sueltos y empieza a comportarse como un lenguaje: vas a conectar la salida de un comando con la entrada del siguiente, guardar resultados en archivos con precisión quirúrgica, y encadenar comandos según si el anterior funcionó o falló en lugar de simplemente asumir que sí. Al cerrar el módulo vas a poder explicar qué son la entrada estándar y las dos salidas de cualquier proceso —y por qué un error sigue apareciendo en pantalla incluso cuando guardaste la salida en un archivo—, construir una tubería de varios comandos que responda una pregunta concreta sobre un archivo de decenas de miles de líneas, y decidir con &&, || y ; qué comando corre después de otro.

La razón por la que esto importa en el trabajo real es simple: nadie que administra servidores, revisa logs de producción o automatiza un flujo de datos hace ese trabajo comando por comando, mirando la pantalla entre cada uno y decidiendo a mano qué escribir después. Lo hace en una línea que dice exactamente qué preguntar y de dónde sacar la respuesta. Esa línea es lo que este módulo te enseña a escribir.

Conexión con el módulo: esta lección es el mapa: qué vas a poder hacer, por qué este módulo cambia tu forma de trabajar más que los dos anteriores juntos, y una advertencia sobre el orden en que lo vamos a construir. La siguiente, La filosofía Unix: herramientas chicas que se combinan, explica la idea de diseño que hace posible todo lo que sigue: por qué el ecosistema Unix apostó por muchos programas pequeños en lugar de uno solo enorme, y qué se gana —y qué se pierde— con esa apuesta.

De comandos sueltos a un lenguaje que compone

Piensa en cómo aprendiste un idioma. Primero, palabras sueltas: agua, casa, comer. Con puro vocabulario ya puedes señalar cosas y nombrarlas. Pero hay una distancia enorme entre nombrar objetos y decir "quiero comer algo antes de llegar a casa porque no hay agua ahí" — esa frase no es vocabulario nuevo, es gramática: la manera de conectar palabras que ya conocías para expresar una idea que ninguna de ellas dice por sí sola.

Los módulos 1 y 2 te dieron vocabulario. ls, cd, find, grep, cat, wc: cada uno nombra algo o hace una cosa puntual. Y son útiles exactamente hasta que la pregunta que tienes en la cabeza necesita más de uno para responderse. "¿Cuál es la IP que más veces le pidió algo a mi servidor esta semana?" no la responde grep solo, ni sort solo —que todavía no conoces—: la responde una frase construida con varios comandos, cada uno entregándole su resultado al siguiente.

Ese es el cambio de este módulo. No vas a aprender un comando más poderoso. Vas a aprender que un comando puede recibir algo, transformarlo y entregárselo a otro, y que esa cadena puede tener el largo que tu pregunta necesite. La forma precisa de decir "cada proceso tiene una entrada y produce dos tipos de salida distintos" es justo lo que vamos a definir con cuidado en la lección 3, y es, sin exagerar, el concepto que más vas a usar el resto de tu carrera trabajando desde una terminal.

Ejemplo trabajado: la pregunta que se responde en el tiempo que tarda en leerse

Vamos a un caso concreto, con el que vas a volver a encontrarte —a mayor escala y con más preguntas— en el proyecto que cierra este módulo. Genera tú mismo un archivo de log de un servidor web, access.log, con cada línea registrando una petición: qué IP la hizo, a qué ruta y con qué resultado. Este bucle no es contenido nuevo del módulo —es el mismo for y el mismo case que existen en cualquier shell—; solo lo usamos para fabricar datos de práctica realistas, con algunas IP mucho más frecuentes que las demás, como pasaría con visitantes habituales o bots:

mkdir -p ~/pipes-preview && cd ~/pipes-preview
for i in $(seq 1 50000); do
  case $((i % 40)) in
    0|1|2|3|4|5|6) ip="203.0.113.45" ;;
    7|8|9|10|11) ip="203.0.113.12" ;;
    12|13|14|15) ip="198.51.100.7" ;;
    16|17) ip="198.51.100.23" ;;
    18) ip="203.0.113.201" ;;
    *) ip="10.0.$((i % 200)).$(((i / 200) % 200))" ;;
  esac
  echo "$ip - - [21/Jul/2026:12:00:00 +0000] \"GET /index.html HTTP/1.1\" 200 512"
done > access.log

Ahora sí, algo que ya sabes hacer desde el módulo 2 —medir el tamaño antes de abrir nada—:

wc -l access.log

Qué esperar:

   50000 access.log

Cincuenta mil líneas. Ábrelo con cat y tu terminal queda inservible un buen rato. Ábrelo en una hoja de cálculo y primero esperas a que cargue, luego separas la columna de la IP con "Texto en columnas", armas una tabla dinámica sobre esa columna, la ordenas de mayor a menor y recién ahí miras las primeras filas. Ese vaivén de menús —cargar, separar, armar la tabla, ordenar, mirar— fácilmente le lleva quince o veinte minutos a quien lo hace por primera vez, para una pregunta que se formula en una sola frase: ¿cuáles son las cinco IP que más pidieron algo?

Así se ve esa misma pregunta escrita para la terminal:

cut -d ' ' -f1 access.log | sort | uniq -c | sort -rn | head -5

Qué esperar:

8750 203.0.113.45
6250 203.0.113.12
5000 198.51.100.7
2500 198.51.100.23
1250 203.0.113.201

Una línea, y la respuesta aparece en el tiempo que tarda la terminal en procesar cincuenta mil líneas: una fracción de segundo, en cualquier máquina moderna. No hace falta que entiendas esa línea todavía. Míralo así: son cinco palabras que reconoces a medias, conectadas por un símbolo que todavía no viste (|). cut, el primer sort, uniq -c y el segundo sort son piezas nuevas —te las presento en la lección 6—, pero head ya lo conoces del módulo 2, y la idea de que la salida de una herramienta se convierte en la entrada de la siguiente es exactamente lo que vas a entender de memoria dos lecciones más adelante. Vuelve a esta línea cuando termines el módulo: vas a poder leerla de corrido y vas a poder escribir una parecida para una pregunta tuya.

Por qué el módulo empieza al revés de lo que esperarías

Lo lógico, después de ver ese ejemplo, sería querer aprender ya mismo qué es esa barra vertical. Vamos a resistir esa tentación durante una lección más, y hay una razón concreta detrás del orden.

Si memorizas que | "conecta comandos" y que > "guarda en un archivo" sin entender qué es lo que en verdad se conecta o se guarda, memorizaste dos hechizos. Funcionan mientras copias el ejemplo exacto que estudiaste, y se rompen apenas la situación cambia un poco —por ejemplo, cuando guardas la salida de un comando que falla y el error igual aparece en tu pantalla, y no tienes idea de por qué, si se supone que le pusiste >—. Ese comportamiento no es un capricho ni una falla: es la consecuencia directa de un hecho que todavía no explicamos, que un proceso no tiene una sola salida, tiene dos, y viajan por caminos distintos.

Por eso la lección 3, Los tres flujos: stdin, stdout y stderr, no te enseña ningún símbolo nuevo. Te da el modelo con el que los símbolos de las lecciones 4 y 5 dejan de ser arbitrarios. Una vez que entiendes que todo proceso nace con una entrada y dos salidas separadas, > deja de ser "el comando para guardar" y pasa a ser "apunta la salida de resultados a otro lugar", y desde ahí puedes razonar sintaxis que nunca viste en lugar de buscarla en internet cada vez que la necesitas.

El mapa del módulo

1. Introducción: comandos que se conectan entre sí         ← estás aquí
2. La filosofía Unix: herramientas chicas que se combinan
3. Los tres flujos: stdin, stdout y stderr
4. Redirigir salida a archivos: >, >>, 2> y /dev/null
5. Tuberías: conectar la salida de un comando con la entrada de otro
6. El kit de texto: sort, uniq, cut, tr y sed
7. Códigos de salida y encadenamiento: $?, &&, || y ;
8. Proyecto: una tubería de análisis de logs

Fíjate en la forma: dos lecciones de teoría (2 y 3) antes de tocar un solo símbolo, cuatro lecciones de mecánica (4 a 7) y un proyecto (8) que junta todo contra un log real —el mismo tipo de archivo que abriste en el ejemplo de arriba, pero con más preguntas y sin que nadie te dé la respuesta servida.

Errores comunes

Confundir "conocer muchos comandos" con "saber resolver problemas en la terminal". Es fácil llegar a este módulo pensando que lo que falta es memorizar un comando número veintiuno, más avanzado que los anteriores. No es así: lo que falta es la gramática que conecta el vocabulario que ya tienes. Se detecta cuando, frente a una pregunta como la del ejemplo de arriba, tu primer instinto es abrir el archivo en un editor y buscar a ojo en lugar de pensar en una cadena de comandos. Se corrige con práctica deliberada de composición —justo lo que este módulo entrena— más que acumulando comandos sueltos.

Querer saltarte la teoría de la lección 3 e ir directo a | y >. Vas a sentir la tentación, sobre todo después del ejemplo de arriba. El problema es que, sin el modelo de las dos salidas separadas, vas a memorizar la sintaxis en vez de entenderla, y ese tipo de memoria se olvida en un par de semanas —lo notas porque tienes que volver a buscar en internet algo que ya usaste el mes pasado—. Se corrige respetando el orden del módulo esta única vez; después ya no vas a necesitar el orden explícito, porque el modelo mental va a estar puesto.

Construir una tubería larga de una sola vez, sin probar cada eslabón. Cuando por fin sepas escribir algo como el ejemplo de arriba, la tentación va a ser escribir los cinco comandos de un tirón y ejecutar todo junto. Si algo sale mal —una salida vacía, un resultado que no tiene sentido—, no vas a saber cuál de los cinco eslabones falló. Se detecta porque el error o el silencio no te dice en qué paso ocurrió. Se corrige construyendo de a un comando por vez, revisando el resultado en cada paso, y agregando el siguiente solo cuando el anterior hace lo que esperabas —es el método completo de la lección 5, pero el hábito conviene empezarlo desde ahora—.

Ejercicios

Ejercicio 1 — ¿Hoja de cálculo o terminal?

Para cada escenario, decide si resolverías la pregunta con una hoja de cálculo, con la terminal, o combinando las dos, y justifica con lo que viste en esta lección: velocidad, escala del archivo, y para qué necesitas el resultado después.

  1. Un archivo de 12 filas con las ventas del trimestre, y necesitas armar un gráfico de barras para una reunión en cinco minutos.
  2. Un log de servidor de 80,000 líneas, y durante un incidente en producción necesitas saber ya mismo cuáles son los cinco códigos de error más frecuentes.
  3. Un archivo de 40,000 líneas de transacciones del que necesitas filtrar solo las de un cliente, contar cuántas hubo por mes, y entregarle el resultado a un gerente que espera una tabla prolija con un gráfico.
Ver solución
  1. Hoja de cálculo. Doce filas es una escala donde no hay fricción real al abrir el archivo, y necesitas un gráfico —algo que una hoja de cálculo hace mucho mejor que la terminal—. Ninguna de las ventajas de este módulo, velocidad sobre archivos enormes y composición de pasos, aplica aquí.
  2. Terminal. Ochenta mil líneas y una pregunta urgente durante un incidente es exactamente el caso del ejemplo de la lección: abrir eso en una hoja de cálculo significa esperar a que cargue y armar una tabla dinámica mientras el problema sigue ocurriendo. Una línea de comandos te da el conteo en segundos.
  3. Las dos, combinadas. Filtrar y contar sobre 40,000 líneas es trabajo de terminal —rápido y preciso—, pero "tabla prolija con gráfico para un gerente" es exactamente lo que una hoja de cálculo hace bien y la terminal no. El patrón real, y el que vas a usar en tu trabajo, es procesar en la terminal y presentar en la hoja de cálculo. No es una competencia entre las dos herramientas.

Por qué funciona: el criterio no es "la terminal siempre gana". Es evaluar escala del archivo, urgencia de la respuesta y qué necesita pasar con el resultado después —los mismos tres factores que separaron el ejemplo de la lección de un caso donde la hoja de cálculo sigue siendo la herramienta correcta.

Ejercicio 2 — Lee antes de ejecutar

Todavía no aprendiste cut, sort ni uniq formalmente —llegan en la lección 6—, pero ya sabes algo que el módulo 1 te enseñó: leer un manual antes de usar un comando. Sin ejecutar nada más que esto, corre los tres comandos y, con lo que veas en cada página, escribe en una frase qué crees que hace cada herramienta:

man cut
man sort
man uniq
Ver solución

No hay una única forma correcta de redactarlo, pero el sentido debería acercarse a esto:

  • cut recorta una parte de cada línea de un archivo —por ejemplo, una columna, cuando los valores están separados por un carácter como el espacio o la coma—.
  • sort ordena las líneas de un archivo o de una entrada, por defecto alfabéticamente.
  • uniq elimina líneas repetidas consecutivas, y puede además contar cuántas veces se repitió cada una.

Por qué funciona: la descripción corta de cada manual —la sección NAME, justo debajo del título— resume en una línea qué hace el comando, sin que necesites entender todavía sus banderas. Es la misma habilidad de la lección 5 del módulo 1, leer antes de ejecutar, aplicada ahora a comandos que vas a aprender formalmente en un rato. Si conectas estas tres frases con la línea del ejemplo de esta lección (cut ... | sort | uniq -c | sort -rn | head -5), ya puedes intuir qué hace cada eslabón, aunque todavía no sepas escribir uno tú mismo.

Ejercicio 3 — Aplica el lente de composición

Tienes que responder esta pregunta sobre tu propia máquina: "¿cuántos archivos con extensión .log se modificaron en los últimos 7 días dentro de /var/log?". Ya conoces find del módulo 2, que sabe filtrar por extensión y por fecha de modificación. Con lo que viste hoy: ¿find solo te da la respuesta final, o vas a necesitar combinarlo con algo más? Justifica.

Ver solución

find puede filtrar y listar los archivos que cumplen esa condición, pero lo que entrega es una lista de rutas, una por línea, no un número. Para llegar a "cuántos", necesitas combinarlo con algo que cuente líneas. Esa pieza ya la conoces: wc -l, del módulo 2. La pregunta completa, entonces, no la responde un solo comando: la responde una composición de dos —exactamente el tipo de razonamiento que este módulo formaliza, aunque la sintaxis exacta para conectarlos, la tubería, todavía no la viste—.

Por qué funciona: reconocer que una pregunta tiene dos partes —"encontrar" y "contar"— y que cada parte ya tiene un comando conocido asignado es el hábito mental central de este módulo. La sintaxis para unirlos es mecánica y la aprendes en la lección 5; el criterio para saber que necesitas unir dos comandos es el que estás entrenando ahora mismo.

Resumen y siguiente paso

Los módulos 1 y 2 te dieron comandos que resuelven preguntas puntuales. Este módulo te da la gramática para conectarlos: la salida de uno se convierte en la entrada del siguiente, puedes decidir con precisión qué guardar y qué descartar, y puedes encadenar comandos según si el anterior tuvo éxito o falló. Viste que ese cambio no es cosmético —una pregunta que en una hoja de cálculo cuesta cinco pasos y media hora, en la terminal es una línea que se lee de corrido en un par de segundos— y por qué el módulo invierte el orden habitual: teoría, los tres flujos, antes que símbolos, para que lo que aprendas se quede.

Antes de avanzar deberías poder:

  • Explicar con tus palabras por qué "conocer muchos comandos" no es lo mismo que "saber conectarlos" para resolver una pregunta que ninguno responde solo.
  • Nombrar, sin mirar el mapa, la idea que la lección 3 va a definir con precisión: una entrada y dos salidas distintas para cada proceso.
  • Leer la línea del ejemplo de esta lección (cut ... | sort | uniq -c | sort -rn | head -5) y decir en voz alta, aunque sea de forma aproximada, qué hace cada eslabón.
  • Decir por qué este módulo enseña teoría antes que sintaxis, al revés de lo que hicieron los módulos 1 y 2.

Lo que sigue no es todavía la sintaxis. Es la idea de diseño que explica por qué existen comandos chicos en lugar de uno gigante que lo haga todo, y por qué esa decisión, tomada en los años setenta, sigue siendo la razón por la que puedes construir la línea de arriba con piezas que nadie diseñó pensando la una en la otra.

Recursos

← Anterior8. Proyecto: auditar un proyecto que no conocesSiguiente →2. La filosofía Unix: herramientas chicas que se combinan