Encadenar y sustituir comandos

1. Tres maneras de unir comandos

Las tres se mezclan libremente en una misma línea. Lo que tienen en común los operadores de la segunda fila es que no conectan ningún canal: cada comando conserva su entrada y su salida. Lo único que deciden es si y cuándo se ejecuta el siguiente.

2. El punto y coma: uno después del otro

El punto y coma separa comandos escritos en la misma línea. La shell los ejecuta en orden, de a uno, esperando a que cada uno termine. Es exactamente lo mismo que escribirlos en líneas separadas:

$ cd ~/practica
$ date; whoami; pwd
lun 12 oct 2026 20:15:08 -03
ana
/home/ana/practica

Lo que define al punto y coma es que es incondicional. El comando siguiente se ejecuta haya pasado lo que haya pasado con el anterior:

$ ls nada.txt; echo "Sigo de todos modos"
ls: cannot access 'nada.txt': No such file or directory
Sigo de todos modos

Sirve para tareas independientes entre sí, y para dejar encargada una secuencia larga sin quedarse esperando entre un paso y otro. Cuando los pasos dependen unos de otros, es la herramienta equivocada, como veremos en la sección 6.

3. El código de salida como verdadero o falso

Para ejecutar según el resultado hace falta saber cuál fue. Lo dice el código de salida, que conocemos desde el tema 3 y que en el tema 22 llamamos la cuarta vía de un comando: un número que cada programa deja al terminar, y que la shell guarda en $?.

Quien haya programado en otros lenguajes notará que está al revés de lo habitual, donde el cero es falso. La razón es práctica: hay una sola manera de salir bien y muchas de salir mal, y conviene tener un número para cada una.

Hay dos comandos que no hacen nada más que terminar con un código fijo. Parecen inútiles, y son la forma más limpia de experimentar:

$ true; echo $?
0
$ false; echo $?
1

Qué cuenta como «éxito» lo define cada programa, y conviene consultarlo, porque no siempre es «no hubo errores». El caso más útil es grep: sale con 0 si encontró alguna línea y con 1 si no encontró ninguna, lo que lo convierte en una pregunta sobre el contenido de un archivo.

4. && : solo si salió bien

En comando1 && comando2, el segundo comando se ejecuta solo si el primero tuvo éxito, es decir, si terminó con código 0.

Se lee como una «y» con sentido de condición: «haz esto, y si funcionó, haz aquello».

$ ls notas.txt && echo "El archivo está"
notas.txt
El archivo está
$ ls nada.txt && echo "El archivo está"
ls: cannot access 'nada.txt': No such file or directory

En el segundo caso, ls falló y el echo no llegó a ejecutarse. Es el operador para encadenar pasos donde cada uno supone que el anterior salió bien, que es lo normal:

La tercera fila muestra por qué importa. Con un punto y coma, un tar que fallara por falta de espacio sería seguido igualmente por el borrado, y los datos se perderían sin copia.

5. || : solo si salió mal

En comando1 || comando2, el segundo comando se ejecuta solo si el primero falló, es decir, si terminó con un código distinto de 0.

Es el complemento, y se lee como una «o»: «haz esto, o si no se pudo, haz aquello». Sirve para reaccionar a un fallo: avisar, intentar una alternativa, o abandonar.

$ cd /noexiste || echo "No se pudo entrar al directorio"
bash: cd: /noexiste: No such file or directory
No se pudo entrar al directorio
$ cd /tmp || echo "No se pudo entrar al directorio"
$ cd -
/home/ana/practica

Los nombres de los dos operadores vienen de la lógica, y el comportamiento también. Para saber si «A y B» es verdadero, si A resulta falso ya no hace falta mirar B. Para «A o B», si A resulta verdadero tampoco. La shell evalúa lo mínimo necesario, y ese ahorro es justamente la ejecución condicional.

6. Por qué cd y rm se unen con &&

La diferencia entre ; y && deja de ser una sutileza cuando el segundo comando es destructivo. Hay un caso que aparece en miles de scripts, y que conviene tener grabado:

cd /tmp/obra; rm -rf *              # peligrosa
cd /tmp/obra && rm -rf *            # correcta

Si el directorio existe, las dos hacen lo mismo. La diferencia aparece el día que /tmp/obra no existe, o está mal escrito:

7. Combinar && y ||

Los dos operadores se pueden encadenar en una misma línea. La shell los recorre de izquierda a derecha, y en cada operador decide con el código de salida de lo último que se ejecutó:

$ ls notas.txt &> /dev/null && echo "Existe" || echo "No existe"
Existe
$ ls nada.txt &> /dev/null && echo "Existe" || echo "No existe"
No existe

La forma A && B || C se usa mucho como un «si… entonces… si no…» de una línea, y casi siempre funciona como tal. No lo es exactamente, y la diferencia es una trampa:

En la tercera fila corren las dos ramas, cosa que un «si no» verdadero nunca haría. Con un echo en el lugar de B, que prácticamente no falla, la construcción es segura. Con un comando que puede fallar, hay que usar la estructura condicional propiamente dicha, if, que es materia del curso siguiente.

Dos precisiones sobre cómo se leen las líneas mixtas. && y || tienen la misma prioridad y se agrupan de izquierda a derecha. Y los dos «atan» más fuerte que el punto y coma: en a && b; c, el comando c se ejecuta siempre.

8. Comandos que son preguntas

Los operadores condicionales rinden de verdad con comandos cuyo único propósito es responder sí o no mediante su código de salida, sin escribir nada. Ya vimos uno; hay dos más que conviene conocer desde ahora:

El corchete es un comando, por extraño que parezca: se llama también test, y sus argumentos son lo que hay entre los corchetes. Por eso los espacios son obligatorios después del que abre y antes del que cierra.

$ [ -d fotos ] && echo "fotos es un directorio"
fotos es un directorio
$ [ -e nada.txt ] || echo "nada.txt no existe"
nada.txt no existe
$ grep -q "pan" tareas.txt && echo "Hay que comprar pan"
Hay que comprar pan
$ command -v tree > /dev/null || echo "tree no está instalado"

Con ellos, las líneas se vuelven prudentes. [ -d respaldo ] || mkdir respaldo crea el directorio solo si no existe. [ -f config ] && cp config config.bak hace la copia solo si hay algo que copiar. El comando test tiene muchas más comprobaciones, de textos y de números, que se estudian a fondo al escribir scripts.

9. Agrupar: llaves y paréntesis

A veces se quiere tratar varios comandos como una unidad: redirigir la salida de todos a un mismo archivo, o hacer depender todo un grupo de una condición. Sin agrupar, una redirección afecta solo al comando que la lleva:

$ date; whoami > /tmp/quien.txt              # solo whoami va al archivo
lun 12 oct 2026 20:22:40 -03
$ { date; whoami; } > /tmp/quien.txt          # los dos
$ cat /tmp/quien.txt
lun 12 oct 2026 20:22:51 -03
ana

Hay dos formas de agrupar, con una diferencia de fondo:

La segunda fila es la razón de ser de los paréntesis. Permiten hacer algo en otro directorio sin tener que volver:

$ (cd /etc && ls | wc -l)
218
$ pwd                                           # seguimos donde estábamos
/home/ana/practica

El cd ocurrió dentro de un proceso hijo, que terminó. Es el mismo principio que vimos con sudo cd y con las tuberías: lo que un proceso cambia de su propio entorno no alcanza al que lo lanzó. Aquí se lo aprovecha a propósito.

Un grupo cuenta como un solo comando para los operadores: cd datos && { limpiar; procesar; } ejecuta los dos pasos solo si se pudo entrar.

10. La sustitución de comandos: $( )

La tercera manera de unir comandos es de otra naturaleza. No conecta canales ni decide ejecuciones: reescribe la línea.

La sustitución de comandos, $(comando), ejecuta el comando que está entre los paréntesis y reemplaza toda la construcción por lo que ese comando escribió en su salida estándar.

Es una de las expansiones que enumeramos en el tema 9, y como todas ellas ocurre antes de que el comando principal se ejecute:

$ echo "Hoy es $(date +%A)"
Hoy es lunes
$ echo "Hay $(ls | wc -l) elementos en $(pwd)"
Hay 4 elementos en /home/ana/practica

echo "Hay $(ls | wc -l) elementos en $(pwd)"
           └─────┬─────┘              └─┬──┘
            se ejecuta: 4          se ejecuta: /home/ana/practica

echo "Hay 4 elementos en /home/ana/practica"        ← la línea que recibe echo

echo nunca supo que hubo otros comandos: recibió un texto ya armado. La diferencia con la tubería es precisamente esa. En una tubería, la salida de un comando llega al otro como datos, por la entrada. En la sustitución, llega como texto de la línea: como argumentos.

Por eso sirve con los comandos que no leen su entrada, los mismos para los que en el tema anterior necesitamos xargs:

$ ls -l $(which bash)
-rwxr-xr-x 1 root root 1446024 mar 31  2024 /usr/bin/bash
$ wc -l $(find . -name "*.txt")
    1 ./notas.txt
  361 ./informe.txt
    5 ./tareas.txt
  367 total

En el primer ejemplo, which bash responde con una ruta, y esa ruta se convierte en el argumento de ls -l. Dos preguntas —«¿dónde está?» y «¿qué permisos tiene?»— en una línea.

La usamos una vez sin explicarla, en el tema 15, para poner la fecha en el nombre de un respaldo: tar -czf practica-$(date +%F).tar.gz. Es su uso más típico: fabricar un nombre con un dato que solo se conoce en el momento.

11. $( ) en detalle

Cuatro propiedades completan el cuadro.

Se quitan los saltos de línea finales. La salida de date termina en un salto de línea, que estorbaría en medio de una frase. La shell lo elimina.

Solo captura la salida estándar. Los mensajes de error del comando interior siguen yendo a la pantalla, por el canal 2, como en una tubería.

Se puede anidar. Los paréntesis permiten poner una sustitución dentro de otra sin ambigüedad:

$ echo "Este directorio se llama $(basename $(pwd))"
Este directorio se llama practica

basename entrega el último componente de una ruta. Primero se resuelve la sustitución de adentro, pwd; su resultado es el argumento de basename.

Sin comillas, el resultado se parte en palabras. Es el punto delicado. El texto que deja la sustitución pasa por la separación en argumentos y por la expansión de comodines, como si lo hubieras escrito. Si contiene espacios, se convierte en varios argumentos:

Existe una forma antigua de la misma construcción, con comillas invertidas o acentos graves: `date` equivale a $(date). La verás en scripts viejos y en mucha documentación. Hace lo mismo, pero se confunde a la vista con las comillas simples y no se puede anidar con comodidad; la forma con paréntesis es la que conviene escribir.

12. Sustitución, tubería o xargs

Hay ya tres maneras de hacer que el resultado de un comando llegue a otro. No son intercambiables:

13. Un paso más: la sustitución de procesos

Queda un caso que las herramientas anteriores no cubren. Algunos comandos necesitan dos entradas, y las esperan como nombres de archivo. El ejemplo típico es diff, que compara dos archivos y que estudiamos en el tema 31. Una tubería solo puede alimentar una entrada.

Bash ofrece una construcción para eso, pariente de la anterior. <(comando) se reemplaza por el nombre de un archivo especial, del que se puede leer la salida de ese comando:

$ echo <(ls)                                    # en qué se convierte
/dev/fd/63
$ diff <(ls /bin) <(ls /usr/bin)                # comparar dos listados
$ 

diff recibió dos nombres de archivo y los comparó, sin saber que eran las salidas de dos comandos. No escribió nada, que en su idioma significa «son idénticos»: una confirmación, por otro camino, de que /bin es un enlace a /usr/bin, como vimos en el tema 8.

El nombre /dev/fd/63 es un descriptor de archivo, de los del tema 22. No hace falta usar esta construcción a menudo; conviene saber que existe para el día en que haga falta comparar o combinar dos salidas sin crear archivos temporales.

14. De la línea al programa

Con todos los operadores del bloque se pueden escribir líneas que hacen un trabajo completo, con sus precauciones. Por ejemplo, un respaldo del directorio de práctica:

$ mkdir -p /tmp/respaldos && tar -czf "/tmp/respaldos/practica-$(date +%F).tar.gz" -C ~ practica && echo "Respaldo listo" || echo "El respaldo falló" >&2
Respaldo listo

La línea funciona, y marca también un límite. Es larga, cuesta leerla, y la próxima vez habrá que reescribirla o buscarla en el historial. Cuando una línea llega a este punto, ha dejado de ser un comando y es un programa que pide un archivo propio: un script. Guardada en un archivo, con cada paso en su renglón, se vuelve legible, repetible y fácil de mejorar. Ese paso lo damos en el tema 41.

La tabla completa de operadores que controlan la ejecución, para cerrar el bloque:

La quinta fila completa la lista y previene una confusión: un solo & no tiene nada que ver con &&. Lanza el comando sin esperar su resultado, y lo vemos al estudiar los procesos.

Con este tema termina el quinto bloque. Sabemos conectar comandos de todas las formas posibles; lo que falta es conocer mejor las piezas que se conectan. El sexto bloque está dedicado a los filtros de texto, y empieza en el tema 26 con los que ya usamos de pasada: sort, uniq, cut y tr.

15. Resumen

• Los comandos se unen por sus datos, con la tubería; por su orden y su resultado, con ;, && y ||; y por su texto, con $( ).
• El punto y coma ejecuta los comandos en secuencia, sin condiciones.
• Un código de salida 0 significa éxito y la shell lo trata como verdadero; cualquier otro, fallo y falso. true y false devuelven siempre uno y otro.
• a && b ejecuta b solo si a tuvo éxito. a || b, solo si a falló.
• Un comando que depende de otro se une con &&, no con punto y coma. El caso clásico es cd directorio && rm …
• a && b || c funciona como una condición de una línea, pero ejecuta c también si b falla.
• [ -f ruta ], [ -d ruta ], grep -q y command -v son comandos que responden sí o no mediante su código de salida.
• Las llaves agrupan comandos en la shell actual; los paréntesis, en una subshell, cuyos cambios de directorio no afectan a la shell.
• $(comando) se reemplaza por la salida de ese comando. Sirve para poner un valor calculado dentro de una línea.
• La sustitución se escribe entre comillas dobles cuando produce un solo valor, para que los espacios no la partan en varios argumentos.
• La tubería entrega datos a un filtro; la sustitución entrega un valor como argumento; xargs aplica un comando a una lista.
• <(comando) ofrece la salida de un comando como si fuera un archivo, para los programas que esperan nombres de archivo.
• Cuando una línea se vuelve larga y difícil de leer, es momento de convertirla en un script.

16. Preguntas de repaso

Intenta responder cada una antes de abrir la respuesta.

Para practicar

1. Predice y luego comprueba la salida de estas líneas: true && echo A; false && echo B; true || echo C; false || echo D; false; echo E.
2. Predice y comprueba: true && false || echo X y false || true && echo Y. Explica cada una paso a paso.
3. Escribe una línea que entre en /tmp/obra y liste su contenido solo si pudo entrar. Pruébala antes y después de crear el directorio.
4. Escribe una línea que diga «Hay tareas pendientes» si tareas.txt existe y no está vacío, y «Nada que hacer» en caso contrario.
5. Con grep -q, escribe una línea que agregue «Comprar leche» al final de una copia de tareas.txt solo si todavía no figura. Ejecútala dos veces y comprueba que la línea no se duplica.
6. Guarda en un solo archivo de /tmp la salida de date, whoami, hostname y uname -r, usando un grupo entre llaves.
7. Con paréntesis, cuenta cuántos elementos hay en /usr/share/doc sin cambiar tu directorio de trabajo. Verifica con pwd.
8. Con la sustitución de comandos, muestra una frase como «Soy ana, estoy en equipo y son las 20:30», tomando cada dato de un comando.
9. Crea un directorio en /tmp cuyo nombre incluya la fecha de hoy, y entra en él con una sola línea.
10. Usa diff con la sustitución de procesos para comparar el listado de /etc/skel con el de los archivos ocultos de tu directorio personal: diff <(ls -A /etc/skel) <(ls -A ~).