Por qué automatizar con Bash

1. Una tarea hecha a mano

Ana mantiene una pequeña aplicación web. La aplicación escribe un archivo de registro por día en ~/app/logs, y si nadie los atiende terminan llenando el disco. Así que cada mañana, antes de empezar a trabajar, Ana abre una terminal y hace esto:

$ cd ~/app/logs
$ ls
app-2026-09-13.log.gz  app-2026-10-12.log.gz  app-2026-10-13.log  app-2026-10-14.log
$ gzip app-2026-10-13.log                # comprimir el registro de ayer
$ find . -name '*.log.gz' -mtime +30     # ¿hay alguno de hace más de un mes?
./app-2026-09-13.log.gz
$ rm ./app-2026-09-13.log.gz
$ df -h .                              # ¿cuánto espacio queda?
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        40G   23G   15G  61% /

Son comandos que ya conoces del curso anterior, y la tarea lleva unos tres minutos. Nada de esto es difícil. El problema está en otra parte:

• Se repite. Tres minutos por día hábil son más de diez horas al año dedicadas a escribir lo mismo.
• Depende de que alguien se acuerde. El día que Ana está de vacaciones, nadie lo hace. Dos semanas después, el disco está lleno y la aplicación deja de responder.
• Invita al error. Un día, apurada, comprime el registro de hoy, que la aplicación todavía está escribiendo. Otro, escribe -mtime +3 en lugar de +30 y borra cuatro semanas de registros.
• Vive solo en su cabeza. Si otra persona tiene que hacerlo, Ana debe explicárselo, y la explicación nunca es exactamente lo que ella hace.

Los cuatro problemas tienen la misma solución: escribir los pasos una vez, en un archivo, y dejar que la computadora los ejecute.

2. Qué es un script

Un script de shell es un archivo de texto que contiene comandos, los mismos que se escribirían en la terminal, y que la shell ejecuta de principio a fin como si alguien los tecleara uno tras otro. A eso se suman variables, condiciones, bucles y funciones, que lo convierten en un programa.

La versión más simple de un script es una lista de comandos guardada en un archivo. La rutina de Ana podría empezar así:

#!/usr/bin/env bash
# Comprime el registro de ayer y borra los de hace más de 30 días.
cd ~/app/logs
gzip "app-$(date -d yesterday +%F).log"
find . -name '*.log.gz' -mtime +30 -delete
df -h .

Comparada con la sesión manual, ya cambiaron dos cosas. El nombre del archivo de ayer no se lee en pantalla: lo calcula date. Y la búsqueda de archivos viejos borra directamente con -delete, porque ya no hay una persona mirando la lista. Que el script deba arreglárselas sin alguien que mire es la diferencia más profunda entre trabajar en la consola y automatizar, y gran parte de este curso trata de sus consecuencias.

$ chmod +x limpiar-registros.sh
$ ./limpiar-registros.sh
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        40G   23G   15G  61% /

Tres minutos de tecleo se convirtieron en un solo comando. Y un comando se puede programar para que se ejecute solo, todos los días a las 3:30 de la mañana, con una línea en la tabla de cron:

30 3 * * *  /home/ana/bin/limpiar-registros.sh

El último bloque del curso de Terminal ya mostró cómo crear un archivo así y darle permiso de ejecución, y el tema 2 lo retoma con detalle. Por ahora importa la idea: un script es la tarea escrita, y lo escrito se puede repetir, revisar, compartir y programar.

3. Qué tareas conviene automatizar

No todo merece un script. Escribirlo, probarlo y mantenerlo cuesta tiempo, y ese costo debe pagarse con lo que ahorra. Estas son las señales de que una tarea es buena candidata:

Y estas son señales de que, al menos por ahora, conviene seguir haciéndolo a mano:

• Se hace una sola vez, o tan de vez en cuando que el script quedaría desactualizado entre una ejecución y la siguiente.
• Requiere juicio en cada paso. Si en cada ejecución hay que mirar algo y decidir qué hacer de un modo que no puede describirse con reglas, el script no tiene de dónde sacar esa decisión.
• Todavía no la entiendes bien. Automatizar un procedimiento confuso produce un procedimiento confuso que se ejecuta más rápido. Primero hay que hacerlo a mano unas cuantas veces.

4. Hacer las cuentas

La decisión de automatizar se puede razonar con números aproximados. Basta multiplicar cuánto dura la tarea por las veces que se hará en, digamos, un año, y compararlo con lo que llevaría escribir el script.

El script de limpieza se escribe y se prueba en una hora; el de despliegue, quizá en una tarde. En ambos casos el ahorro es grande. Pero la cuenta subestima el beneficio, porque solo mide minutos. Un despliegue manual que falla una vez al año por un paso olvidado puede costar más que todo el tiempo de la tabla.

La cuenta también sirve en sentido contrario. Pasar dos días perfeccionando un script para algo que se hace una vez al año y lleva diez minutos es un mal negocio, aunque resulte entretenido. La excepción son las tareas raras pero delicadas, como restaurar una copia de seguridad: se hacen poco, pero cuando hacen falta no hay margen para improvisar.

5. Más que tiempo

El ahorro de tiempo es el argumento más visible, pero rara vez el más importante. Una tarea automatizada gana otras cualidades:

Hay un último beneficio, más sutil: escribir el script obliga a entender la tarea. Para que una máquina la haga hay que contestar preguntas que a mano se resuelven sin pensar. ¿Qué pasa si el directorio no existe? ¿Y si hoy no hubo registro? ¿Y si el disco está lleno? Responderlas mejora el procedimiento aunque nunca se llegue a automatizar.

6. Por qué Bash

Cualquier lenguaje de programación puede automatizar tareas. Bash no es el más elegante ni el más rápido, y tiene rarezas que este curso no va a disimular. Aun así, para automatizar tareas de un sistema es casi siempre la primera opción, por cinco razones:

La segunda razón merece subrayarse. La mayor parte de lo que necesitas para automatizar ya lo aprendiste en el curso de Terminal: los comandos, las redirecciones, las tuberías, grep, sed y awk. Lo que agrega este curso es lo que hace falta para que esos comandos funcionen solos: guardar datos en variables, tomar decisiones, repetir, organizar el código y reaccionar ante los errores.

7. Un lenguaje para unir programas

Bash se describe a menudo como un lenguaje pegamento. Su fuerza no está en lo que hace por sí mismo, que es poco, sino en coordinar programas que ya existen y que hacen muy bien una sola cosa. Un script de Bash rara vez comprime, compila o copia por red: le pide a gzip, a gcc o a rsync que lo hagan, y se ocupa de decidir cuándo, con qué datos y qué hacer si algo sale mal.

Para ver la diferencia, piensa en esta tarea: «empaqueta el directorio del proyecto con la fecha en el nombre y cópialo al servidor de respaldos». En Bash son dos líneas, porque cada paso es un programa que ya existe:

archivo="proyecto-$(date +%F).tar.gz"
tar -czf "$archivo" ~/proyecto && scp "$archivo" respaldos@servidor:/copias/

En un lenguaje de propósito general la misma tarea requiere una biblioteca para comprimir, otra para la conexión segura, y el manejo de sus errores. Se puede hacer, y a veces es lo correcto, pero no es lo más directo. En Bash, lo más directo es justamente esto.

8. Lo que Bash hace mal

La otra cara del pegamento es que Bash es un lenguaje pobre para casi todo lo que no sea coordinar comandos. Conviene conocer sus límites desde el principio, para no forzarlo donde no rinde.

Tres ejemplos breves dan una idea de cómo se manifiestan. El primero, la aritmética: Bash solo calcula con enteros.

$ echo $(( 7 / 2 ))
3
$ echo $(( 1.5 + 2 ))
bash: 1.5 + 2 : syntax error: invalid arithmetic operator (error token is ".5 + 2 ")

El segundo, los espacios. Una variable que contiene un nombre de archivo con un espacio se parte en dos si no se la pone entre comillas:

$ archivo="informe final.txt"
$ touch "$archivo"
$ ls -l $archivo                       # sin comillas: dos argumentos
ls: cannot access 'informe': No such file or directory
ls: cannot access 'final.txt': No such file or directory
$ ls -l "$archivo"                     # con comillas: uno
-rw-r--r-- 1 ana ana 0 oct 14 09:12 informe final.txt

El tercero es el más peligroso: un comando falla y el script sigue adelante.

#!/usr/bin/env bash
cd /var/tmp/compilacion
rm -rf ./*

Ninguno de estos problemas es motivo para evitar Bash. Son motivo para aprenderlo bien: casi todos tienen una solución conocida, y este curso las presenta una por una. Pero sí son motivo para reconocer cuándo una tarea ha dejado de ser adecuada para Bash.

9. Cuándo elegir otra herramienta

Bash es la herramienta correcta cuando la tarea consiste sobre todo en ejecutar programas, mover archivos y conectar resultados. Cuando consiste sobre todo en procesar datos, calcular o modelar algo complejo, conviene otra. Esta tabla resume las alternativas más comunes:

En la práctica, las herramientas conviven. Un sistema de integración continua ejecuta un script de Bash, que llama a make para compilar y a un pequeño programa en Python para generar un informe. Elegir no es casarse con un lenguaje: es usar cada uno donde rinde.

Hay señales claras de que un script ha crecido más de la cuenta y conviene reescribirlo en otro lenguaje:

• Supera las 150 o 200 líneas y sigue creciendo.
• Necesita estructuras de datos complicadas: listas de listas, registros con varios campos, árboles.
• Pasa más tiempo extrayendo y transformando datos con sed y awk que ejecutando programas.
• Hace cálculos con decimales o fechas más allá de lo trivial.
• Nadie se anima a modificarlo, porque no hay forma de probar que sigue funcionando.

10. Bash y sh: una nota sobre portabilidad

Como viste en el primer tema del curso de Terminal, Bash desciende de la shell de Bourne, sh. El lenguaje de sh está fijado por un estándar, POSIX, que respetan todas las shells de la familia. Bash cumple ese estándar y le agrega muchas comodidades: [[ ]], los arrays, la aritmética con (( )), las expresiones regulares con =~ y otras.

De ahí surge una decisión que todo script toma en su primera línea:

Este curso escribe scripts de Bash, con la segunda línea, porque Bash está en casi cualquier sistema Linux y sus agregados hacen los scripts más seguros y legibles. El error que conviene evitar es otro: escribir un script con características de Bash y encabezarlo con #!/bin/sh. En Debian y Ubuntu, /bin/sh no es Bash sino dash, que no las entiende, y el script falla de formas desconcertantes. El tema 2 explica cómo funciona esa primera línea.

11. Un primer vistazo a un script real

Volvamos al script de Ana. Esta es la versión que podrías escribir al terminar el bloque 6. No hace falta entenderla ahora: está aquí para mostrar hacia dónde va el curso, y para que reconozcas, línea por línea, de qué tema sale cada pieza.

#!/usr/bin/env bash
# limpiar-registros.sh — comprime los registros anteriores a hoy
# y borra los comprimidos de más de N días.
# Uso: limpiar-registros.sh [directorio] [días]
set -euo pipefail

dir="${1:-$HOME/app/logs}"
dias="${2:-30}"
hoy="$(date +%F)"

if [[ ! -d "$dir" ]]; then
  echo "Error: no existe el directorio $dir" >&2
  exit 1
fi

comprimidos=0
for archivo in "$dir"/*.log; do
  [[ -e "$archivo" ]] || continue             # no hay ningún .log
  [[ "$archivo" == *"$hoy"* ]] && continue     # el de hoy sigue en uso
  gzip "$archivo"
  comprimidos=$(( comprimidos + 1 ))
done

borrados=$(find "$dir" -name '*.log.gz' -mtime +"$dias" -print -delete | wc -l)
echo "Comprimidos: $comprimidos · Borrados: $borrados"

Comparada con la primera versión de la sección 2, esta hace lo mismo, pero se comporta de otra manera cuando algo no es como se esperaba:

$ limpiar-registros.sh                        # con los valores por defecto
Comprimidos: 1 · Borrados: 1
$ limpiar-registros.sh /srv/web/logs 15       # otro directorio, otro plazo
Comprimidos: 6 · Borrados: 4
$ limpiar-registros.sh /no/existe
Error: no existe el directorio /no/existe
$ echo $?                                     # el código de salida informa del fallo
1

Y, programado con cron, registra en un archivo lo que hizo cada noche, de modo que se pueda revisar después. Los detalles de esa línea son el tema 34:

30 3 * * *  /home/ana/bin/limpiar-registros.sh >> /home/ana/limpieza.log 2>&1

12. Las cualidades de un buen script

La diferencia entre la primera versión y la última no está en lo que hacen cuando todo va bien, sino en lo que hacen cuando algo va mal. Un script que se ejecuta solo, sin nadie mirando, tiene que cumplir exigencias que un comando escrito a mano no necesita. Estas son las que guían todo el curso:

Ningún script necesita todas estas cualidades desde la primera línea. Un script de cinco líneas para uso propio puede prescindir de casi todas. Pero cuanto más importante es la tarea, y cuanto menos supervisión tiene, más de ellas hacen falta.

13. Automatizar con cuidado

La automatización amplifica: hace lo correcto más rápido y más veces, pero también hace lo incorrecto más rápido y más veces. Un error que a mano afecta a un archivo, en un bucle afecta a todos. Algunas precauciones que retomaremos a lo largo del curso:

1. Prueba primero a mano. Ejecuta cada comando en la terminal antes de guardarlo en el script, y comprueba que hace lo que esperas.
2. Prueba sin consecuencias. Cambia el rm o el gzip por un echo que solo muestre qué se haría. Cuando la lista es la correcta, quita el echo. Muchos scripts ofrecen esto como una opción, a menudo llamada --dry-run.
3. Prueba en un lugar seguro. Un directorio de prueba con archivos de mentira, o una máquina virtual, nunca los datos reales en la primera ejecución.
4. Comprueba antes de borrar. Que el directorio existe, que la variable no está vacía, que estás en la máquina correcta. Un rm -rf "$dir/"* con dir vacía se convierte en rm -rf /*.
5. No escribas contraseñas dentro del script. Los scripts se copian, se comparten y se guardan en repositorios. Las credenciales van en archivos aparte, con permisos restringidos, o en variables de entorno.
6. Deja rastro. Un script que se ejecuta solo debe anotar qué hizo. Si un día algo falla, el registro es lo único que tendrás para averiguar qué pasó.
7. Revisa que siga funcionando. Una tarea automatizada que falla en silencio es peor que una manual: nadie se entera hasta que es tarde. El tema 40 trata de cómo recibir un aviso cuando algo no anda.

14. El mapa del curso

Los 42 temas están ordenados para que cada bloque agregue a tus scripts una capacidad nueva. Cada uno responde una pregunta:

Los bloques 2 a 5 enseñan el lenguaje; el 6 es el que separa un script que funciona de uno en el que se puede confiar; del 7 al 9 se aplica todo a tareas reales. En el tema 2 escribimos, ejecutamos e instalamos el primer script.

15. Resumen

• Un script de shell es un archivo con comandos que la shell ejecuta de principio a fin. Con variables, condiciones, bucles y funciones se convierte en un programa.
• La diferencia profunda entre la consola y un script es que el script debe funcionar sin nadie que mire la salida y decida.
• Conviene automatizar lo que se repite, tiene muchos pasos, es caro de hacer mal, debe ocurrir a una hora fija o se aplica a muchos elementos.
• No conviene automatizar lo que se hace una sola vez, lo que requiere juicio en cada paso ni lo que todavía no se entiende bien.
• Además de tiempo, la automatización aporta consistencia, documentación, delegación, revisión, registro y escala.
• Bash es la primera opción para automatizar en Linux porque ya está instalado, es el lenguaje de la consola y ejecutar programas es su operación básica.
• Bash es un lenguaje pegamento: no hace el trabajo pesado, coordina a los programas que lo hacen.
• Sus puntos débiles son la ausencia de decimales y de estructuras de datos, los problemas con espacios y comillas, los errores que pasan en silencio y el rendimiento.
• Para datos estructurados y cálculos conviene Python; para compilar, make; para configurar muchos servidores, herramientas como Ansible. Las herramientas se combinan.
• #!/bin/sh promete un script POSIX; #!/usr/bin/env bash, uno que necesita Bash. Usar características de Bash bajo sh es un error frecuente.
• Un buen script es legible, parametrizable, prudente, honesto con su código de salida, claro en sus errores, limpio y repetible.
• La automatización amplifica los errores: hay que probar a mano, probar sin consecuencias y comprobar antes de borrar.

16. Preguntas de repaso

Intenta responder cada una antes de abrir la respuesta.

Para practicar

1. Haz una lista de cinco tareas que repites en tu computadora o en tu trabajo. Para cada una, anota cuánto dura, cada cuánto la haces y cuántas de las señales de la sección 3 cumple.
2. Elige la tarea de la lista con más tiempo al año y escribe, en un archivo de texto, los comandos exactos con que la harías en la terminal. Es el borrador de tu primer script.
3. Para esos mismos pasos, anota qué podría salir mal en cada uno: un archivo que no existe, un disco lleno, una conexión caída. Esas notas son las comprobaciones que el script necesitará.
4. Ejecuta echo $(( 10 / 3 )) y echo "10 / 3" | bc -l. Compara los resultados.
5. Crea un archivo con un espacio en el nombre y prueba a listarlo con una variable, con y sin comillas, como en la sección 8.
6. Averigua qué es /bin/sh en tu sistema con ls -l /bin/sh. ¿Es un enlace a Bash, a dash o a otra shell?
7. Instala ShellCheck y comprueba que funciona con shellcheck --version.