Al cerrar el Módulo 3 quedó un muro señalado con el dedo: la línea de crontab llena de escapes, la tubería del informe que ya no cabía en la pantalla, y esa dependencia insoportable de que tú te acordaras de cada paso a las tres de la madrugada. Este módulo derriba ese muro con la idea más simple del mundo: un script no es más que un fichero de texto con los comandos que ya sabes escribir.

No hay lenguaje nuevo que aprender: grep, awk, find, curl y df siguen siendo los mismos. Lo que cambia es que dejan de vivir en tu memoria para vivir en un fichero con nombre, permisos, autor y fecha; un fichero que puede ejecutarse igual mil veces y correr solo cuando tú duermes. Esta lección monta los cimientos y termina con revision_salud.sh, el primer script del hilo conductor, que las seis lecciones siguientes irán mejorando.

1. ¿Merece esto ser un script?
2. Qué es exactamente un script
3. El shebang: quién interpreta tu fichero
4. Las tres formas de ejecutar un script
5. Permisos de ejecución
6. Dónde viven los scripts y el PATH
7. Anatomía de un script decente
8. Comentarios útiles y comentarios inútiles
9. Códigos de salida
10. Primer script real: revision_salud.sh
11. Estilo y herramientas: shellcheck y shfmt

Escribir un script tiene un coste: hay que mantenerlo, versionarlo, documentarlo y recordar que existe. Antes de abrir el editor, sitúa lo que quieres hacer en esta escala.

La regla práctica: si lo has hecho tres veces a mano, o si va a ejecutarlo alguien que no eres tú, o si va a ejecutarlo cron, es un script. Si además empieza a manejar datos anidados o a hablar con APIs JSON, la alarma está sonando y toca mirar hacia Python; volveremos a ello en 04-07. La revisión de salud que Marta pide cada mañana cumple los tres criterios a la vez: es un script.

Un fichero de texto plano con comandos que el intérprete lee y ejecuta en orden. No se compila, no se enlaza, no genera binarios.

bash ha abierto el fichero, ha leído la primera línea, la ha ejecutado como si tú la hubieras tecleado, y ha pasado a la segunda. Esa equivalencia total entre «lo que tecleas» y «lo que va en un script» es la razón de que este módulo te resulte natural: ya sabes escribir el contenido, solo faltaba el recipiente.

Si el fichero se ejecuta por sí mismo, el kernel necesita saber qué programa debe interpretarlo: lo dicen los dos primeros caracteres, #!, seguidos de la ruta del intérprete. Al ejecutar ./script.sh, el kernel lee esos bytes mágicos y arranca en realidad /bin/bash ./script.sh. Sin shebang el resultado depende de dónde estés, así que nunca lo dejes al azar.

En este curso usaremos #!/usr/bin/env bash: cuesta lo mismo y te ahorra el día en que ejecutes el script en un macOS donde el Bash moderno está en /opt/homebrew/bin/bash.

En Ubuntu y Debian, ls -l /bin/sh revela un enlace a dash, un shell minúsculo que implementa POSIX y nada más. Se eligió así porque los scripts de arranque son miles y dash los ejecuta mucho más rápido. La consecuencia es que todo lo específico de Bash falla:

El mismo fichero, dos intérpretes, dos resultados. [[ ]] es de Bash, igual que los arrays, ${VAR^^}, local -n o <<<. Y observa el detalle cruel: el script no falló al escribirlo, falló al ejecutarse con el intérprete equivocado, posiblemente semanas después y dentro de cron. Si escribes #!/bin/sh, no uses nada de Bash.

Hay tres —bash script.sh arranca un Bash nuevo que lee el fichero, ./script.sh deja que el kernel lea el shebang, y source script.sh (o . script.sh, la forma POSIX) lo ejecuta el shell actual— y la diferencia no es cosmética: cambia en qué proceso se ejecutan tus comandos.

La demostración clásica, un script que cambia de directorio:

El script sí cambió de directorio... en su propio proceso, que ya no existe. Un hijo hereda una copia del entorno de su padre, pero nada de lo que el hijo cambie vuelve al padre: ni el directorio, ni las variables, ni las funciones. Es la herencia de una sola dirección de 03-01; con source no hay proceso nuevo y por eso el cd persiste.

Dos reglas prácticas. Los scripts se ejecutan con ./ o por su nombre, la única forma que respeta el shebang y la que usará cron. Y source se reserva para configuración y librerías de funciones, que es para lo que lo usaremos en 04-05. Un aviso: como source no crea proceso, un exit 1 dentro de un fichero que haces source en tu terminal te cierra la sesión. Le ha pasado a todo el mundo una vez.

Un fichero de texto no es ejecutable hasta que se lo dices al sistema. Retomando 02-07:

chmod +x respeta el umask 027 del Módulo 2: añade x a usuario y grupo, no a otros; chmod 750 dice lo mismo sin depender del umask. Dos matices: el bit x no significa «esto es código máquina» sino «permíteme intentar ejecutarlo» —quien decide cómo interpretarlo es el shebang—, y bash script.sh funciona sin bit x porque ahí el fichero solo se lee, que es la forma cómoda de probar algo a medio escribir.

Teclear /home/operador/scripts/revision_salud.sh cada mañana garantiza que nadie lo use. La solución es el PATH, que ya diseccionaste en 03-01.

Usamos un enlace simbólico en vez de mover el fichero: el código sigue en ~/scripts (versionado en git, ya en 04-07) y ~/bin solo publica un nombre cómodo, sin extensión y con guiones, como los comandos de Unix. Sigue vigente la regla del Módulo 3: . nunca en el PATH, porque bastaría con que alguien dejara un fichero llamado ls en un directorio compartido para que ejecutaras su código sin saberlo.

Esta es la plantilla con la que vas a empezar todos tus scripts desde hoy. Cada línea evita un problema concreto que verás durante el módulo.

• Cabecera. Nombre, propósito, autor, fecha y modo de uso: cuando dentro de ocho meses encuentres este fichero a las cuatro de la mañana, esas cinco líneas valdrán más que todo lo demás.
• set -euo pipefail. El modo estricto: -e aborta si un comando falla, -u aborta si usas una variable no definida, y pipefail hace que una tubería falle si falla cualquiera de sus tramos, no solo el último (lo anunciamos en 03-04). Ponlo desde hoy en todo lo que escribas; el porqué detallado y —sobre todo— dónde no funciona es el corazón de 04-06.
• Constantes en MAYÚSCULAS, minúsculas para las variables de trabajo, y todas agrupadas arriba: cambiar un umbral no debe obligar a leer el script entero.
• exit 0 explícito. Sin él, el script devuelve el código del último comando, que puede ser cualquier cosa. exit 0 dice «he llegado hasta aquí y todo fue bien», y eso es lo que leen cron y la monitorización.

Todo lo que sigue a # se ignora hasta el fin de línea, salvo el shebang. Pero comentar mucho no es comentar bien.

La regla: el código dice qué hace; el comentario dice por qué. Si necesitas un comentario para entender qué hace una línea, la solución suele ser reescribirla o extraerla a una función con buen nombre (04-05).

Todo proceso termina devolviendo un entero de 0 a 255. Ya lo conoces como $?; ahora tú eres quien lo produce, y eso cambia la responsabilidad: el código de salida es la única parte de tu script que otro programa va a leer. La convención es al revés de lo intuitivo —0 es éxito— y tiene sentido: hay una sola forma de acertar y muchas de fallar, cada una con su número.

(Y exit -1 acaba en 255, fuera de rango.) exit sin argumento devuelve el código del último comando: sé explícito. Y evita inventarte códigos por encima de 125, que chocan con los reservados; tienes de sobra con el rango 3-125 para tus propios significados, documentados en la cabecera. En 04-03 formalizaremos una tabla para nuestros scripts.

Marta pide lo mismo cada mañana: «¿está la web arriba, queda disco, y hubo errores esta noche?». Lo escribimos tal cual, como una tirada de comandos, aplicando la plantilla del apartado anterior.

Ya es infinitamente mejor que tres comandos en el historial. Pero es honestamente malo, y conviene que veas por qué desde el principio, porque esa lista es el índice del resto del módulo:

• Las constantes están dentro del script y no acepta opciones: ni -h, ni un umbral distinto, ni modo silencioso (04-02 y 04-03).
• Imprime el umbral pero no lo compara con nada. No hay ninguna decisión: si el disco estuviera al 95 % diría «95%» tan tranquilo (04-04).
• Tres bloques casi idénticos que piden a gritos ser funciones (04-05), y si errores.log no existe el script muere a medias con un mensaje feo (04-06).
• Siempre devuelve 0, así que ninguna monitorización puede usarlo (04-07).

Guárdalo tal cual: al final del módulo lo compararás con su versión final.

Bash tiene una sintaxis llena de trampas y un intérprete que casi nunca se queja: escribe $fichero sin comillas y funcionará durante meses, hasta el día en que aparezca un nombre con un espacio. El análisis estático no es opcional en shell.

Tres avisos en cuatro líneas y los tres son bombas de relojería: sin comillas, un directorio con espacios se parte en dos argumentos; y si el cd falla, el rm -f se ejecuta en el directorio en el que estuvieras. Cada código SCxxxx tiene su página en el wiki de ShellCheck; en 04-06 desmenuzaremos los cuatro más frecuentes. La regla del módulo desde hoy: ningún script se da por terminado hasta que shellcheck no dice nada.

shfmt formatea en lugar de criticar: -i 4 fija cuatro espacios, -d enseña qué cambiaría sin tocar nada (la costumbre de --dry-run del curso) y -w escribe. Sobre estilo, tres decisiones que no discutiremos más: cuatro espacios de indentación (nunca tabuladores, que se rompen al copiar), líneas de menos de 100 caracteres partiendo con \, y una instrucción por línea.

• Escribir el script en Windows y subirlo. Los finales CRLF hacen que el shebang sea #!/usr/bin/env bash\r y el error, bad interpreter: No such file or directory, no dice nada. Diagnostícalo con file script.sh y arréglalo con dos2unix.
• Dejar líneas antes del shebang. Debe ser la primera línea, empezando en la columna 1. Y no llames test.sh a tu script: test es un builtin y el conflicto de nombres da quebraderos de cabeza.
• Ejecutar con sh script.sh un script con shebang de Bash. El shebang se ignora cuando invocas el intérprete a mano: es la causa número uno de «funciona en mi terminal y falla en el servidor».
• Esperar que un script cambie tu directorio o tus variables. No puede: es otro proceso. Si de verdad lo necesitas, es una función o un fichero para source. Y no olvides el exit 0 final: si la última línea es un grep sin coincidencias, tu script correcto devuelve 1 y cron te avisa de un fallo inexistente.
• Consejo: durante el desarrollo, bash -n script.sh comprueba la sintaxis sin ejecutar nada; cuesta un segundo y evita descubrir un fi que falta a mitad de un despliegue. Integra además shellcheck en tu editor y empieza cada script copiando la plantilla del apartado 7.

Ejercicio 1. Demuestra empíricamente, con un solo fichero y sin editarlo entre pruebas, la diferencia entre bash script.sh, ./script.sh y source script.sh. El script debe definir una variable, cambiar de directorio e imprimir su propio PID. Explica qué observas en cada caso y por qué.

Ejercicio 2. Escribe ~/scripts/info_release.sh: qué versión de Tramontana está activa (resolviendo /opt/tramontana/app), cuánto ocupa ese release y cuándo se desplegó. Aplica la plantilla completa, déjalo limpio de shellcheck y publícalo en ~/bin como info-release.

Ejercicio 3. Luis ha dejado este script en el servidor. Encuentra cuatro problemas distintos sin ejecutarlo, justifica cada uno y reescríbelo.

Solución 1. $$ contiene el PID del shell que ejecuta el código: es el testigo que delata si ha habido proceso nuevo.

bash /tmp/demo_ambito.sh da el mismo resultado que ./: PID distinto del de tu shell, luego proceso nuevo, y el cd y la variable mueren con él. Solo cambia el mecanismo: bash fichero arranca Bash explícitamente e ignora el shebang, mientras que ./fichero hace que el kernel lea el shebang y decida —y por eso ese caso, y solo ese, exige el bit x—. El tercero imprime el mismo PID 3120: no hay proceso nuevo, lo ha ejecutado tu propio Bash, y por eso todo persiste. El ${MI_VARIABLE:-(no existe)} evita que echo imprima un vacío ambiguo; lo verás en detalle en 04-02.

Solución 2.

Solución 3. Los cuatro problemas, de más grave a menos:

1. cd sin comprobar seguido de rm -rf *. El defecto letal: si el directorio no existe o no tienes permiso, el cd falla, el script continúa donde estuvieras y borra todo lo que haya allí. Es SC2164, y se arregla con cd ... || exit o con modo estricto.
2. #! /bin/sh con [[ ]]. Dos errores: el espacio tras #! lo admite Linux pero no todos los Unix, y sobre todo /bin/sh es dash, que no conoce [[ ]]. El script muere en la última línea con [[: not found.
3. if [[ $? == 0 ]]. Redundante y frágil: en Bash se ramifica directamente sobre el comando (if rm -rf ...; then), como veremos en 04-04. Además == compara cadenas donde debería usarse un test numérico.
4. Falta todo lo demás: sin cabecera, sin modo estricto, sin exit explícito, y el comentario «limpia temporales» no dice qué considera temporal ni desde cuándo. Un rm -rf * merece más explicación que ninguna otra línea del fichero.

La versión reescrita hace además lo que el nombre promete —borrar lo antiguo, no todo—:

Ya no hay cd, así que el peligro desaparece de raíz, y el modo estricto aborta si find falla.

Tienes los cimientos, y son más de los que parece.

• Sabes cuándo escribir un script y cuándo basta un alias, una función o Ansible, con la regla de las tres repeticiones como criterio.
• Entiendes que un script es texto plano con comandos, dominas el shebang y por qué #!/usr/bin/env bash es la elección por defecto, y conoces la trampa de que en Ubuntu /bin/sh es dash y [[ ]] no existe allí.
• Distingues las tres formas de ejecutar un script y por qué solo source afecta a tu shell; colocas los scripts en ~/scripts, los publicas con un enlace en ~/bin y sigues sin poner . en el PATH.
• Arrancas todo script con la misma plantilla —shebang, cabecera con uso, set -euo pipefail, constantes en mayúsculas, cuerpo y exit 0—, comentas el porqué, devuelves códigos de salida con significado y pasas shellcheck antes de dar nada por terminado.

revision_salud.sh ya existe y ya funciona, pero tiene las constantes clavadas en el código, no compara nada y no sabe decir si el resultado es bueno o malo. En la próxima lección, Variables y Tipos de Datos, atacamos la primera carencia: verás que en Bash todo es una cadena y qué implica eso, dominarás la expansión de parámetros —esa colección de ${VAR#...}, ${VAR:-...} y ${VAR//.../...} que convierte diez líneas en una—, aprenderás por qué Bash no sabe sumar decimales y qué hacer con el importe medio de reservas.csv, y contarás reservas por casa con arrays asociativos sin salir del shell. Al terminarla, revision_salud.sh tendrá su configuración fuera del cuerpo del script.