# Redirecciones y tuberías en la terminal

**Categoría:** Linux y sistemas · **Nivel:** Intermedio · **Lectura:** 12 min
**Publicada:** 2026-07-28 · **Actualizada:** 2026-07-28 · **Autoría:** Underc0de
**Versión HTML (canónica):** https://underc0de.org/guias/linux/redirecciones-y-tuberias-en-la-terminal/

## Respuesta rápida

La terminal de Linux es potente por una idea simple: cada comando tiene una **entrada** y dos **salidas** estándar, y se pueden **conectar entre sí**. Los tres «flujos» son: **stdin** (la entrada, por defecto el teclado), **stdout** (la salida normal, por defecto la pantalla) y **stderr** (la salida de errores, también a la pantalla pero separada). Con **redirecciones** cambiás de dónde viene o adónde va cada flujo: > guarda la salida en un archivo (sobrescribiendo), >> la **añade** al final, < toma la entrada de un archivo, y 2> redirige los **errores** por separado. Con **tuberías** (el símbolo |) conectás la *salida* de un comando con la *entrada* del siguiente, encadenándolos. Así, ps aux | grep nginx | wc -l lista procesos, filtra los que dicen «nginx» y cuenta cuántos hay —tres comandos simples resolviendo juntos algo que ninguno hace solo—. Esta es la **filosofía de Unix**: programas pequeños que hacen una cosa bien y se combinan como piezas de Lego. Dominar tuberías y redirecciones es lo que convierte la terminal en una herramienta de verdad, y es la base sobre la que se escriben los [scripts](../bash-scripting-desde-cero/index.md).

## Los tres flujos

Todo comando en Linux nace conectado a tres **flujos estándar**. Entenderlos es la base de todo lo demás:

- **stdin** (entrada estándar): de dónde *lee* el comando. Por defecto, el teclado.
- **stdout** (salida estándar): adónde *escribe* su resultado normal. Por defecto, la pantalla.
- **stderr** (salida de error): adónde escribe sus *mensajes de error*. También la pantalla, pero es un **flujo separado** de stdout.

> **Por qué stderr está separado**
>
> Que los errores vayan por un flujo **distinto** de la salida normal es genial: te permite, por ejemplo, guardar los resultados en un archivo mientras los errores siguen apareciendo en pantalla, o al revés. Si estuvieran mezclados, no podrías separarlos después. Esta separación es la que hace posible el registro limpio en [tareas programadas](../tareas-programadas-en-linux-cron-y-timers/index.md) y scripts.

## Redirecciones

Una **redirección** cambia el destino o el origen de un flujo. Las esenciales:

```text
comando > salida.txt      # stdout a un archivo (SOBRESCRIBE lo que hubiera)
comando >> salida.txt     # stdout AÑADIDO al final del archivo
comando < entrada.txt     # toma stdin desde un archivo
comando 2> errores.txt    # stderr (los errores) a un archivo aparte
comando > todo.txt 2>&1   # salida Y errores al mismo archivo
comando 2> /dev/null      # descarta los errores (los "tira")
```

> **Atención**
>
> > **sobrescribe**: borra el contenido previo del archivo y pone la nueva salida. >> **añade** al final, conservando lo que había. Confundirlos es un error clásico: un > donde querías >> puede **borrar un registro** entero de golpe. Para logs, casi siempre querés >>.

2>&1 significa «manda stderr al mismo sitio que stdout»; es la fórmula habitual para capturar **todo** en un log. Y /dev/null es un «agujero negro» del sistema: lo que redirigís ahí, se descarta.

## Tuberías

La **tubería** (el símbolo |, «pipe») es la estrella: toma la **salida** de un comando y la entrega como **entrada** al siguiente. Encadenando comandos simples se resuelven tareas que ninguno hace solo:

```text
ps aux | grep nginx | wc -l    # procesos → filtra "nginx" → cuenta líneas
ls -l | sort -k5 -n            # lista archivos → ordena por tamaño
cat acceso.log | grep 404 | tail -20 # log → solo 404 → últimas 20
history | grep git             # tu historial → solo comandos con "git"
```

Cada comando hace **una cosa**: grep filtra, sort ordena, wc cuenta, tail muestra el final. Solos son limitados; **combinados** resuelven casi cualquier cosa. Esa es la **filosofía de Unix**: piezas pequeñas y componibles, en vez de un programa gigante que lo intente todo. Es exactamente el mismo pegamento con el que se construyen los [scripts](../bash-scripting-desde-cero/index.md).

## Errores frecuentes

- **Usar > donde querías >>.** Sobrescribe el archivo en vez de añadir; para logs, usar >>.
- **Olvidar que > borra el destino.** Redirigir a un archivo con datos lo pisa sin avisar; verificar el nombre.
- **No capturar stderr en scripts.** Los errores se pierden; usar 2>&1 para registrarlos junto a la salida.
- **Encadenar sin necesidad (*«useless cat»*).** cat archivo | grep x es grep x archivo; no siempre hace falta la tubería.
- **Redirigir un flujo que va por stderr.** Si el resultado sale por error, > no lo captura; usar 2>.
- **Esperar que | pase archivos.** La tubería pasa **texto** (la salida), no nombres de archivo; para eso hay otras técnicas.
- **Redirigir a la vez de entrada y salida al mismo archivo.** comando < f > f puede vaciarlo; usar un archivo temporal.

## Preguntas frecuentes

**¿Qué son stdin, stdout y stderr?**
stdin, stdout y stderr son los tres flujos estándar con los que nace conectado todo comando en Linux, y constituyen la base del funcionamiento de la terminal. stdin, o entrada estándar, es el canal por el que un comando recibe los datos que va a procesar, y por defecto está conectado al teclado, de modo que lo que se escribe llega al comando. stdout, o salida estándar, es el canal por el que el comando emite su resultado normal, y por defecto está conectado a la pantalla, razón por la que se ve el resultado de los comandos al ejecutarlos. stderr, o salida de error, es un canal separado por el que el comando emite específicamente sus mensajes de error y advertencias, y también está conectado por defecto a la pantalla, pero es importante entender que es un flujo distinto e independiente de stdout, aunque ambos aparezcan mezclados en la pantalla. La existencia de estos tres flujos, y en particular la separación entre la salida normal y la salida de error, es lo que permite toda la flexibilidad de la terminal: gracias a que están definidos de forma estándar, se pueden redirigir a archivos o conectar entre comandos de forma predecible. La separación de stderr respecto de stdout es especialmente valiosa, porque permite, por ejemplo, guardar los resultados de un comando en un archivo mientras los errores siguen mostrándose en pantalla, o registrar unos y otros por separado, algo imposible si estuvieran combinados en un único flujo.

**¿Cuál es la diferencia entre > y >>?**
Los operadores de redirección de salida con un signo mayor que y con dos signos mayor que hacen algo parecido pero con una diferencia crucial en cómo tratan el archivo de destino. El operador de un solo signo mayor que redirige la salida estándar de un comando a un archivo sobrescribiendo su contenido, lo que significa que borra por completo cualquier contenido que el archivo tuviera previamente y lo reemplaza por la nueva salida; si el archivo no existía, lo crea. El operador de dos signos mayor que, en cambio, redirige la salida al archivo añadiéndola al final, es decir, conservando todo el contenido anterior y agregando la nueva salida a continuación; si el archivo no existía, también lo crea. Esta diferencia, aparentemente pequeña, tiene consecuencias importantes en la práctica. Cuando se quiere ir acumulando información en un archivo a lo largo del tiempo, como ocurre típicamente con los registros o logs, se debe usar la forma de dos signos, porque de lo contrario cada nueva escritura borraría todo lo anterior. El error de usar un solo signo donde se pretendía dos es un fallo clásico que puede provocar la pérdida completa del contenido de un archivo importante en un instante, ya que la sobrescritura se produce sin ninguna advertencia ni confirmación. Por eso conviene interiorizar bien la distinción: un signo para crear o reemplazar el contenido de un archivo, y dos signos para añadir sin destruir lo que ya había.

**¿Qué es una tubería y cómo se usa?**
Una tubería, representada por el símbolo de barra vertical, es un mecanismo que conecta la salida estándar de un comando directamente con la entrada estándar del comando siguiente, de manera que el resultado que produce el primero se convierte en el material que procesa el segundo, sin pasar por la pantalla ni por archivos intermedios. Su uso es sencillo: se escriben dos o más comandos separados por el símbolo de la tubería, y los datos fluyen de izquierda a derecha a través de la cadena. Por ejemplo, se puede tomar la lista de procesos que genera un comando, pasarla por una tubería a otro comando que filtre solo las líneas que contienen cierto texto, y pasar ese resultado filtrado por otra tubería a un tercer comando que cuente cuántas líneas quedaron, obteniendo así, en una sola línea, un dato que ningún comando por separado produce. Esta capacidad de encadenar es enormemente potente porque permite construir operaciones complejas combinando comandos simples, cada uno especializado en una tarea concreta como filtrar, ordenar, contar o mostrar. La tubería es, de hecho, la materialización de la filosofía de diseño de Unix, según la cual es preferible tener muchos programas pequeños que hagan una sola cosa bien y puedan combinarse entre sí, en lugar de programas grandes y monolíticos que intenten hacerlo todo. Dominar el uso de las tuberías es lo que marca la diferencia entre usar la terminal de forma básica, ejecutando comandos aislados, y usarla de forma realmente productiva para resolver problemas combinando herramientas.

**¿Qué significa 2>&1?**
La expresión formada por el número dos, el signo mayor que, y el signo ampersand seguido del número uno es una redirección que significa, en esencia, enviar la salida de error al mismo destino al que va la salida normal. Para entenderla hay que saber que los flujos estándar tienen números asociados: la salida estándar es el número uno y la salida de error es el número dos. Cuando se escribe el número dos seguido del signo mayor que, se está redirigiendo específicamente la salida de error; y la parte con el ampersand seguida del número uno indica que el destino de esa redirección debe ser el mismo lugar al que en ese momento apunta la salida estándar, es decir, el flujo número uno. El resultado combinado es que tanto la salida normal como los errores acaban yendo al mismo sitio. Este uso es muy habitual cuando se quiere capturar absolutamente todo lo que produce un comando, tanto sus resultados como sus mensajes de error, en un único archivo de registro, lo que es especialmente útil en scripts y en tareas programadas donde no hay nadie mirando la pantalla y se necesita un registro completo para poder diagnosticar después qué ocurrió. Es importante el orden al combinarlo con una redirección de la salida normal a un archivo: primero se redirige la salida estándar al archivo y después se indica que el error vaya a donde va la salida estándar, de modo que ambos terminen en el archivo. Esta fórmula, aunque al principio parezca críptica, se vuelve un recurso cotidiano en cuanto se empieza a registrar la salida de comandos y scripts.

**¿Qué es /dev/null?**
El elemento conocido como dev null es un dispositivo especial del sistema Linux que se comporta como un sumidero o agujero negro para los datos: todo lo que se escribe o se redirige hacia él simplemente se descarta y desaparece, sin almacenarse en ningún sitio. Aunque técnicamente aparece como un archivo dentro de la jerarquía de dispositivos del sistema, no es un archivo normal, sino un dispositivo virtual proporcionado por el propio sistema operativo cuyo único propósito es aceptar y desechar cualquier cosa que reciba. Su utilidad práctica es descartar salidas que no interesan. El caso más habitual es redirigir hacia dev null la salida de error de un comando cuando esos errores son irrelevantes o esperables y no se quieren ver, o redirigir la salida normal cuando solo interesa saber si el comando tuvo éxito o no, pero no su resultado en sí. Por ejemplo, en un script se puede ejecutar una comprobación descartando toda su salida y quedándose únicamente con el hecho de si funcionó o falló. También sirve para silenciar comandos ruidosos o para probar el rendimiento de una operación sin el coste de escribir realmente los datos en ningún lado. Conviene usarlo con cierta precaución, porque descartar la salida de error puede ocultar problemas reales que habría sido útil conocer, de modo que enviar los errores a dev null es apropiado solo cuando se está seguro de que esos errores no importan. En resumen, dev null es la forma estándar y limpia de decirle al sistema que tire a la basura una salida que no se necesita.

**¿Por qué se dice que las tuberías reflejan la filosofía de Unix?**
Se dice que las tuberías reflejan la filosofía de Unix porque son la encarnación práctica de uno de los principios de diseño más influyentes de la historia de la informática, que puede resumirse en la idea de crear programas pequeños que hagan una sola cosa y la hagan bien, y diseñarlos para que puedan combinarse entre sí. En lugar de construir aplicaciones enormes y monolíticas que intenten cubrir todas las necesidades por sí solas, la tradición de Unix propone disponer de un conjunto de herramientas modestas y especializadas, cada una experta en una tarea concreta como filtrar texto, ordenar líneas, contar palabras, buscar patrones o mostrar el principio o el final de un flujo. El valor de este enfoque solo se materializa plenamente si esas piezas se pueden ensamblar, y ahí es donde entran las tuberías, que actúan como el pegamento universal que permite conectar la salida de una herramienta con la entrada de otra, formando cadenas capaces de resolver problemas arbitrariamente complejos a partir de componentes simples. Esta composición tiene ventajas profundas: cada herramienta es más fácil de escribir, entender, probar y mantener por ser pequeña; las mismas piezas se reutilizan en infinitas combinaciones distintas según la necesidad; y el usuario obtiene una flexibilidad enorme sin que nadie haya tenido que anticipar cada caso de uso concreto. Por eso las tuberías no son solo una característica técnica cómoda, sino la expresión de una manera de pensar el software que ha demostrado ser extraordinariamente duradera y que sigue inspirando el diseño de sistemas hoy en día.

## Fuentes

Documentación oficial y material de la comunidad consultados para esta guía. Fecha de consulta: 28 de julio de 2026.

### Aportes de la comunidad Underc0de

1. **Underc0de, foro.** [Sección GNU/Linux](https://underc0de.org/foro/gnu-linux/). Terminal y línea de comandos.
2. **Underc0de, blog.** [Blog de la comunidad](https://underc0de.org/blog/). Artículos de sistemas.

### Documentación oficial

1. **GNU.** [Bash Reference: Redirections](https://www.gnu.org/software/bash/manual/bash.html#Redirections). Referencia oficial de redirecciones.
2. **The Linux Documentation Project.** [I/O redirection](https://tldp.org/LDP/abs/html/io-redirection.html). Explicación de referencia.
3. **man7.org.** [pipe(7)](https://man7.org/linux/man-pages/man7/pipe.7.html). Página de manual sobre tuberías.
4. **Bell Labs.** [The Evolution of Unix](https://www.bell-labs.com/usr/dmr/www/hist.html). Origen de la filosofía de composición.

## Guías relacionadas

- [Comandos útiles de Linux](../comandos-utiles-de-linux/index.md)
- [Bash scripting](../bash-scripting-desde-cero/index.md)
- [Procesos y señales](../procesos-y-senales-en-linux/index.md)
- [Tareas programadas](../tareas-programadas-en-linux-cron-y-timers/index.md)
- [Índice de Linux y sistemas](../index.md)