Cómo automatizar tareas repetitivas con scripts de Bash

Conviene automatizar con Bash aquellas tareas que son repetitivas, propensas a cometer errores cuando se hacen manualmente, o que deben ejecutarse sin supervisión, ya que en esos casos el esfuerzo de crear y mantener un script se ve recompensado con creces, mientras que no conviene automatizar tareas que se realizan una sola vez o que son tan variables que el script resultaría más complejo que hacerlas a mano. El error habitual de quien acaba de aprender a programar en Bash es querer automatizarlo todo, sin darse cuenta de que automatizar tiene un coste, que incluye escribir el script, probarlo para asegurarse de que funciona correctamente y mantenerlo cuando cambian las circunstancias. Por eso la pregunta correcta no es si algo se puede automatizar, ya que casi todo se puede, sino si merece la pena hacerlo, es decir, si el ahorro que produce compensa el coste de crearlo y mantenerlo. Las tareas que son buenas candidatas para la automatización comparten ciertas características. En primer lugar, las tareas repetitivas que se realizan con frecuencia, como una limpieza diaria de archivos temporales o la generación de un informe semanal, ya que automatizarlas ahorra tiempo cada vez que se ejecutan y ese ahorro se acumula. En segundo lugar, las tareas propensas a error cuando se hacen a mano, especialmente aquellas que consisten en una secuencia de pasos en la que olvidar o equivocar uno tiene consecuencias, ya que un script realiza siempre los mismos pasos en el mismo orden sin fallos de despiste. En tercer lugar, las tareas que deben ejecutarse sin una persona presente, como un backup programado durante la madrugada, que solo se pueden realizar de forma desatendida mediante un script programado. Por el contrario, no merece la pena automatizar las tareas que se hacen una única vez y que no se repetirán, ya que el tiempo de escribir el script superaría al de hacer la tarea directamente, ni las tareas tan variables o dependientes del juicio humano que un script que las cubriera todas resultaría más complejo y frágil que realizarlas manualmente. Aplicar este criterio de merecer la pena es el primer paso para automatizar de forma sensata y productiva, evitando invertir esfuerzo en scripts que no aportan un beneficio real.

Los patrones prácticos de automatización más útiles en Bash son tres, que juntos cubren la mayoría de las tareas de automatización reales: recorrer un conjunto de archivos para procesarlos, aceptar argumentos para hacer el script reutilizable, y comprobar las condiciones antes de actuar para evitar errores. El primer patrón es recorrer archivos mediante un bucle. Muchas tareas de automatización consisten en hacer lo mismo con todos los archivos de una carpeta, como convertir un conjunto de imágenes, renombrar una serie de archivos, comprimir varios documentos o procesar un lote de datos. El patrón consiste en usar un bucle que itera sobre los archivos de un directorio y ejecuta las acciones deseadas sobre cada uno, lo que permite procesar automáticamente cualquier cantidad de archivos con el mismo esfuerzo. El segundo patrón es aceptar argumentos, que convierte un script de un solo uso en una herramienta reutilizable. En lugar de escribir dentro del script los valores concretos con los que va a trabajar, como una ruta, un nombre o una opción, lo que obligaría a editar el script cada vez que se quiere usar con valores distintos, el script se diseña para recibir esos valores como argumentos cuando se le llama. De este modo, el mismo script sirve para muchos casos diferentes simplemente pasándole distintos argumentos, sin necesidad de modificarlo. El tercer patrón es comprobar antes de actuar, que es fundamental para evitar errores y desastres. Consiste en verificar que se cumplen las condiciones necesarias antes de realizar una acción, por ejemplo comprobar que un archivo que se va a procesar realmente existe, que una variable que contiene una ruta no está vacía antes de operar sobre ella, o que un comando previo del que depende el siguiente paso ha terminado correctamente antes de continuar. Este patrón evita que el script actúe sobre un estado incorrecto y cause daños. Estos tres patrones no son independientes, sino que suelen combinarse en un mismo script de automatización, que por ejemplo puede recibir mediante argumentos la carpeta a procesar, comprobar que existe, y recorrer sus archivos realizando comprobaciones sobre cada uno antes de actuar. Dominar estos patrones y saber combinarlos es lo que permite pasar de conocer la sintaxis de Bash a construir automatizaciones útiles y fiables que resuelven problemas reales del día a día en la administración de sistemas.

Para que un script de Bash se ejecute automáticamente a una hora determinada o con una periodicidad concreta, sin necesidad de lanzarlo manualmente, se utiliza el programador de tareas del sistema, siendo las opciones principales en Linux el clásico cron y los temporizadores del sistema de gestión de servicios moderno. Un script de automatización a menudo tiene sentido precisamente porque se quiere que se ejecute solo, a su hora, sin que nadie tenga que estar presente para lanzarlo, como en el caso de un backup nocturno, una limpieza periódica o la generación regular de un informe. La herramienta tradicional y más conocida para esto es cron, que es un servicio del sistema que ejecuta tareas programadas según una configuración en la que se indica con qué periodicidad debe ejecutarse cada tarea, permitiendo especificar el minuto, la hora, el día del mes, el mes y el día de la semana, lo que da una gran flexibilidad para definir cuándo se ejecuta el script, ya sea cada pocos minutos, todos los días a una hora concreta, una vez por semana o con casi cualquier otra periodicidad. Cada usuario puede tener sus propias tareas programadas, y también existen tareas programadas a nivel del sistema. La alternativa moderna son los temporizadores del sistema de gestión de servicios, que ofrecen una funcionalidad equivalente a la de cron pero integrada en dicho sistema, con algunas ventajas como un mejor registro de la ejecución, la posibilidad de ejecutar tareas que no pudieron correr a su hora, y una integración más estrecha con el resto de los servicios. Independientemente de la herramienta elegida, hay algunas consideraciones importantes al programar un script para que se ejecute automáticamente. La primera es que el script debe ser robusto, ya que al ejecutarse sin supervisión, si falla en silencio puede causar problemas que nadie detecte hasta que sea tarde. La segunda es que el entorno en el que se ejecuta una tarea programada suele ser más limitado que el de una sesión interactiva, por lo que conviene usar rutas completas y no dar por supuestas variables de entorno que sí existen cuando se ejecuta el script manualmente. La tercera es que es muy recomendable que el script registre lo que hace en un archivo de registro, de modo que se pueda comprobar después si se ejecutó correctamente y qué resultado tuvo. Combinando un script bien escrito con una programación adecuada mediante cron o los temporizadores, se consigue una automatización fiable que trabaja por sí sola de forma regular.

Un script de automatización es robusto cuando está escrito para desconfiar del estado del sistema y manejar los posibles fallos en lugar de suponer que todo irá bien, lo que se consigue aplicando una serie de reglas concretas que evitan que el script cause daños al ejecutarse, especialmente cuando corre de forma desatendida. La diferencia fundamental entre un script frágil y uno robusto no está en la sintaxis ni en lo sofisticado que sea, sino en la actitud con la que está escrito: un script robusto asume que las cosas pueden salir mal, que un archivo puede no existir, que un disco puede estar lleno, que un comando previo puede haber fallado o que una variable puede venir vacía, y prevé y maneja esas situaciones. Las reglas concretas que hacen robusto a un script son varias. La primera es hacer que el script se detenga ante el primer error, ya que por defecto Bash continúa ejecutando los comandos siguientes aunque uno falle, lo que puede llevar a que el script prosiga sobre un estado roto y cause daños; configurarlo para que se detenga si un comando falla evita este peligro. La segunda es tratar el uso de variables no definidas como un error, ya que un simple error de escritura en el nombre de una variable puede hacer que esta se evalúe como vacía y provoque comportamientos desastrosos, como operar sobre una ruta vacía; hacer que usar una variable inexistente sea un error detiene el script antes del problema. La tercera es entrecomillar siempre las variables, porque si no se hace, un valor que contenga espacios, como un nombre de archivo con espacios, se dividirá en varios elementos y el script hará cosas inesperadas; entrecomillar las variables preserva su valor como una unidad. La cuarta es comprobar las condiciones antes de actuar, verificando que existe lo necesario y que los pasos previos funcionaron antes de realizar acciones, especialmente las destructivas. La quinta es registrar lo que hace el script en un archivo de registro, de modo que cuando se ejecute sin supervisión quede constancia de qué procesó y con qué resultado. Y la sexta es avisar de los fallos en lugar de dejarlos pasar inadvertidos, devolviendo códigos de error y notificando los problemas. Un ejemplo clásico que ilustra la importancia de la robustez es un script que cambia a un directorio y luego borra su contenido: si el cambio de directorio falla porque este no existe y el script no se ha detenido ante el error, el borrado se ejecutaría en el directorio equivocado, con consecuencias potencialmente catastróficas. Aplicar estas reglas, y apoyarse en herramientas de análisis que detectan errores clásicos, es lo que convierte un script de juguete en uno apto para producción.

ShellCheck es una herramienta de análisis estático para scripts de shell, incluidos los de Bash, que examina el código del script sin ejecutarlo y señala errores, malas prácticas y construcciones problemáticas, ayudando a escribir scripts más correctos y robustos y a detectar fallos antes de que causen problemas en la ejecución. El análisis estático significa que ShellCheck revisa el texto del script y lo interpreta para encontrar problemas potenciales, en lugar de ejecutarlo y ver qué pasa, lo que permite detectar errores de forma anticipada y segura, sin riesgo de que el propio análisis provoque daños. Los tipos de problemas que ShellCheck detecta son muy variados y cubren muchos de los errores clásicos que cometen tanto los principiantes como los usuarios experimentados de Bash. Entre ellos destacan las variables que no están entrecomilladas, que son una de las fuentes más comunes de comportamientos inesperados cuando los valores contienen espacios o caracteres especiales; las comprobaciones mal escritas o frágiles; el uso incorrecto de construcciones del lenguaje; las confusiones habituales entre distintas formas de hacer una cosa; y muchas otras malas prácticas que pueden hacer que un script funcione en apariencia pero falle en casos concretos. Para cada problema que encuentra, ShellCheck no solo lo señala indicando la línea, sino que suele explicar por qué es un problema y cómo corregirlo, lo que además de arreglar el script concreto ayuda a aprender a escribir mejor Bash. ShellCheck se puede usar de varias formas, incluyendo una versión accesible desde el navegador en la que se pega el script y se obtienen los avisos, una herramienta de línea de comandos que se puede instalar en el sistema para analizar los scripts localmente, y una integración en muchos editores de código que muestra los avisos mientras se escribe. Incorporar el hábito de pasar los scripts por ShellCheck antes de darlos por terminados es una práctica muy recomendable que ahorra numerosos disgustos, ya que atrapa una gran cantidad de errores que de otro modo solo se descubrirían al ejecutar el script, a veces en el peor momento y con consecuencias no deseadas. Es, por tanto, una herramienta muy valiosa en el proceso de escribir scripts de automatización fiables, y complementa a las buenas prácticas de robustez, ayudando a aplicarlas correctamente y a detectar dónde no se están respetando.

No, esta guía no sustituye a aprender Bash desde cero, sino que la complementa y la da por supuesta, ya que se centra en el nivel siguiente, que es cómo aplicar los conocimientos de Bash para automatizar tareas reales de forma útil y fiable, mientras que aprender Bash desde cero cubre los fundamentos del lenguaje que son la base necesaria para todo lo demás. Aprender Bash desde cero abarca los conceptos y la sintaxis fundamentales del lenguaje, como las variables y cómo se usan, las estructuras condicionales que permiten tomar decisiones, los bucles que permiten repetir acciones, la forma de recibir entradas y mostrar salidas, el uso de funciones, y en general la gramática y las construcciones básicas con las que se escribe un script. Este conocimiento es imprescindible y constituye el punto de partida obligatorio, ya que sin dominar la sintaxis no es posible escribir ningún script. Esta guía, en cambio, parte de que esos fundamentos ya se conocen y se ocupa de una habilidad distinta y de nivel superior, que es la automatización práctica, es decir, cómo pasar de saber escribir instrucciones de Bash a construir automatizaciones que resuelven problemas reales de forma robusta. Para ello aborda cuestiones que no son de sintaxis sino de criterio y de práctica, como decidir qué tareas merece la pena automatizar, aplicar los patrones prácticos que se repiten en las automatizaciones reales, programar la ejecución de los scripts para que corran solos a su hora, y, sobre todo, escribir scripts robustos que no fallen en silencio ni causen daños cuando se ejecutan sin supervisión. Estos son aspectos que la enseñanza de la sintaxis básica no suele cubrir, pero que son precisamente los que marcan la diferencia entre saber escribir un script y saber automatizar de verdad. Por tanto, la relación entre ambas es de complementariedad y de progresión: primero se aprenden los fundamentos de Bash, que enseñan a escribir scripts, y después se aprende a automatizar, que enseña a usar esos scripts para resolver problemas reales de manera fiable. Quien no domine todavía los fundamentos debería empezar por ellos, ya que son la base sobre la que se construye todo lo que esta guía explica, mientras que quien ya sepa escribir scripts básicos encontrará aquí las claves para dar el salto a la automatización profesional y segura.