En las tres lecciones anteriores has escrito if, case y [[ ]] guiándote por el parecido con otros lenguajes. Funcionaba, pero no sabías por qué. Toca arreglarlo empezando por la idea que en Bash lo gobierna todo y que casi ningún tutorial enuncia con claridad: aquí no se ramifica según un valor booleano, se ramifica según el código de salida de un comando. if no espera una expresión: espera un comando, lo ejecuta y mira si devolvió 0; todo lo demás —[ ], [[ ]], (( ))— son comandos que existen para producir ese 0 o 1. Con esa pieza en su sitio, el resto encaja solo. Al final, revision_salud.sh sabrá decir OK, AVISO o CRÍTICO, y nacerá purgar_releases.sh.

1. La condición es un código de salida
2. if, elif, else
3. Los tres tipos de test y cuál usar
4. Tabla completa de operadores
5. Expresiones regulares con =~ y BASH_REMATCH
6. case y sus tres terminadores
7. Bucles: for, while, until
8. break, continue y select
9. Cortocircuitos && y ||, y su trampa
10. Bucles y rendimiento: cuándo quieres awk
11. Aplicación: niveles de alerta y purgar_releases.sh

No hay ningún == true por ninguna parte. if ejecutó grep -q, grep devolvió 0 porque encontró coincidencias, y 0 significa éxito, así que se entró en el then. Si no hubiera encontrado nada habría devuelto 1 y se habría saltado el bloque.

Tres consecuencias que conviene tener presentes desde ya:

• Cualquier comando puede ser una condición: if ping -c1 -W2 10.0.2.15, if [[ -f fichero ]], if mi_funcion. Todos son lo mismo. Y el [ clásico es un comando de verdad, con su ejecutable en /usr/bin/[; por eso [ $a = $b ] necesita espacios: son argumentos separados.
• La lógica está invertida respecto a los lenguajes con booleanos: 0 es verdadero. Si escribes una función que comprueba algo, debe devolver 0 cuando la respuesta es «sí».

La sintaxis exige then y fi; el ; antes de then permite ponerlo en la misma línea. Los elif se evalúan en orden y el primero que acierta gana, así que las condiciones van de la más restrictiva a la más laxa: si intercambiaras los dos primeros bloques, un disco al 95 % diría AVISO. Para negar, ! delante: if ! systemctl is-active --quiet tramontana; then .... Y ojo con if [ $? -eq 0 ], casi siempre redundante: pon el comando directamente en el if.

La diferencia entre [ ] y [[ ]] no es cosmética. [[ ]] es sintaxis del propio shell, no un comando, así que Bash no divide en palabras ni expande globs dentro de él:

Con [ ] la variable sin comillas se partió en dos argumentos y el comando ni siquiera pudo evaluarse. Con [[ ]] no hace falta entrecomillar, y además admite &&, ||, patrones y =~, que [ ] no tiene. Para números, (( )) es mucho más legible: compara if (( errores > 20 && conexiones >= 200 )) con [ "$errores" -gt 20 -a "$conexiones" -ge 200 ]. Recuerda de 04-02 que dentro de (( )) las variables van sin $.

La confusión clásica merece un aviso en negrita: -eq es para números y == para cadenas. [[ "01" -eq "1" ]] es cierto (numéricamente iguales) pero [[ "01" == "1" ]] es falso (cadenas distintas). Usar el operador equivocado da resultados correctos durante meses y luego falla con un cero a la izquierda o con una versión como 3.10.

Otro detalle que sorprende: dentro de [[ ]], el lado derecho de == no se entrecomilla si quieres que sea un patrón:

Las comillas convierten el patrón en texto literal: es la fuente número uno de «mi comparación no funciona y no sé por qué».

=~ compara con una expresión regular extendida (la ERE de 03-02) y, además de decir sí o no, deja las capturas en el array BASH_REMATCH: la posición 0 es la coincidencia completa y las siguientes, los grupos entre paréntesis.

Con esto validas la columna fecha de reservas.csv antes de fiarte de ella. Dos reglas de oro: la regex no va entre comillas —si la entrecomillas se vuelve texto literal, igual que con ==— y si la guardas en una variable, úsala también sin comillas: [[ $f =~ $PATRON ]].

case compara una cadena contra patrones de globbing —no expresiones regulares— y ejecuta la primera rama que case.

El orden importa: 404 va antes que 4* porque gana el primero que case. | separa alternativas y *) es el caso por defecto, que va el último y conviene poner siempre. Los tres terminadores:

;;& es raro pero útil para etiquetas acumulativas; ;& es peligroso porque un lector distraído no lo ve. Úsalos solo con un comentario que lo justifique.

La segunda forma —iterar sobre un glob— es la correcta para recorrer ficheros, y trae dos avisos. El primero: si el glob no encuentra nada, Bash deja el patrón literal y el bucle se ejecuta una vez con /var/log/tramontana/*.log como valor; de ahí el [[ -e ... ]] || continue, o bien shopt -s nullglob de 03-02. El segundo, más importante:

Nunca escribas for f in $(ls).

Lo verás en internet constantemente y está mal por tres motivos acumulativos: ls devuelve texto que el shell parte por espacios, así que «informe agosto.txt» se convierte en dos elementos; los caracteres especiales del nombre se expanden como globs; y ls puede colorear o alinear según opciones y alias. El glob no tiene ninguno de esos problemas porque Bash trabaja con nombres de fichero reales, no con texto. Y existe la forma aritmética, for (( i = 0; i < ${#versiones[@]}; i++ )), para cuando el índice importa.

while repite mientras la condición devuelva 0; until repite hasta que devuelva 0. Son la misma estructura con la condición negada, y until gana cuando la frase natural es «espera hasta que»:

Ese bucle es el que necesita un despliegue para esperar a que el servicio esté listo, y lo reutilizaremos en 04-07. Ya conoces además el while read de 04-03, que es el tercer uso habitual.

break sale del bucle y continue salta a la siguiente iteración. Ambos aceptan un número que indica cuántos niveles afectan: break 2 sale de dos bucles anidados de golpe.

Si te encuentras con tres niveles de anidamiento, eso no es un problema de bucles: es una función que aún no has escrito, y lo veremos en 04-05. En cuanto a select, es un bucle y sin break no termina nunca; PS3 es el texto del aviso y $REPLY guarda lo que tecleó el usuario.

Ya los usas desde 02-01: A && B ejecuta B solo si A tuvo éxito; A || B ejecuta B solo si A falló. Como condicional de una línea son insuperables: [[ -d $DIR ]] || mkdir -p "$DIR", o command -v shellcheck >/dev/null || { echo "falta shellcheck" >&2; exit 69; }. Pero mucha gente escribe condicion && accion || otra_cosa creyendo que es un if/else, y no lo es:

La clave: || no mira la condición, mira el resultado de la acción anterior. Si la acción falla por cualquier motivo —un mkdir sin permiso, un grep sin coincidencias— la rama del || se ejecuta además de la del &&. La regla: encadena && y || solo cuando la acción no pueda fallar; en cuanto haya un else de verdad, usa if.

Este apartado te ahorrará horas de espera. Contemos las 14 respuestas 500 de acceso.log de dos formas:

Trescientas veces más rápido, y solo con 412 líneas. La causa no es que Bash interprete despacio: es que el bucle lanza un proceso grep por cada línea, y crear un proceso cuesta unos milisegundos que se multiplican. Con las 10.000 líneas que tendrá acceso.log en un mes, el bucle tardaría casi un minuto y awk seguiría en centésimas. La regla:

• Si el bucle procesa texto línea a línea, probablemente quieres awk (o grep, sed, sort), que hacen una sola pasada dentro de un único proceso.
• Si el bucle debe llamar a un comando externo en cada vuelta —curl, systemctl, tar— entonces sí es trabajo de Bash, porque no hay alternativa. Y si necesitas Bash sobre texto, al menos no lances procesos dentro: read con varios nombres, case y expansión de parámetros hacen mucho sin salir del shell.

revision_salud.sh por fin decide. Sustituimos el bloque de impresión por comprobaciones con nivel:

Con esos códigos —0 correcto, 1 aviso, 2 crítico— el script ya sirve para monitorización: Nagios, Zabbix y compañía usan exactamente esa convención. Y el script nuevo:

Justo lo que queríamos: solo 3.1.0 es purgable. Fíjate en dos detalles defensivos: rm -rf -- "${DIR_RELEASES:?}/$v" usa ${VAR:?} de 04-02 para que, si la variable quedara vacía por un error, el comando aborte en vez de convertirse en rm -rf /; y -- evita que un nombre de directorio con guion inicial se lea como opción.

• Olvidar los espacios dentro de [ ] o [[ ]]. [[$a == $b]] da orden no encontrada: los corchetes son comandos y palabras reservadas, no sintaxis pegada.
• Mezclar -eq con cadenas o == con números. [[ "3.10" > "3.9" ]] es falso lexicográficamente: para versiones, sort -V; para números, (( )). Y no entrecomilles el lado derecho de == o =~, o el patrón se vuelve texto literal.
• for f in $(ls). Se rompe con espacios y con caracteres especiales; usa siempre el glob. Y protege el glob sin coincidencias con [[ -e $f ]] || continue o shopt -s nullglob, o el bucle correrá una vez con el patrón literal.
• Confiar en cond && accion || otra como if/else. Si accion falla, se ejecutan las dos ramas. Y anidar tres bucles es la señal inequívoca de que falta una función.
• Consejo: compara números siempre con (( )): es más legible y no confundirás el operador. Pon siempre la rama *) en un case, aunque solo sea para registrar «valor inesperado». Y antes de escribir un bucle que procese texto, pregúntate si awk lo haría de una pasada: casi siempre la respuesta es sí.

Ejercicio 1. Escribe es_version_valida(), que devuelva 0 si su argumento tiene el formato N.N.N (uno o más dígitos por tramo) y 1 si no, usando =~, e imprima los tres números por separado. Pruébala con 3.2.1, 3.10.0, 3.2 y v3.2.1.

Ejercicio 2. Escribe ~/scripts/resumen_franjas.sh, que sobre acceso.log clasifique cada petición en madrugada (00-05), mañana (06-13), tarde (14-21) o noche (22-23) con case, y muestre peticiones y errores por franja. Hazlo sin lanzar procesos dentro del bucle y compara el tiempo con awk.

Ejercicio 3. Luis ha escrito este fragmento para decidir si hay que purgar. Encuentra los cuatro defectos y reescríbelo.

Solución 1.

Los puntos van escapados (\.) porque en una regex . significa «cualquier carácter»; sin escapar, 3x2y1 también sería válida. Y fíjate en cómo la función se usa directamente en el if: es el apartado 1 en acción. (Sin return 0 explícito, la función devuelve el código del printf, que es 0.)

Solución 2.

Los 15 errores de madrugada son los de la franja de las 03:00 que ya conoces, y los 23 totales cuadran. La versión en awk —una línea con substr($2,1,2)+0 y el ternario para la franja— tarda 0,007 s: siete veces menos aun sin procesos dentro del bucle, solo por el coste del intérprete. Pero fíjate en la escala: centésimas contra centésimas. La diferencia catastrófica aparece cuando hay $(...) dentro del bucle, no por el bucle en sí. Y nota el patrón [45]* del case: globbing, no regex.

Solución 3. Los cuatro defectos:

1. ` ` en vez de $( ). Las backticks no se anidan, tienen reglas de escape distintas y son ilegibles. Además $5 de df incluye el %, así que la comparación numérica recibe 30%.
2. [ $libre > 80 ]. Dentro de [ ], > no compara: es una redirección, así que ese comando crea un fichero llamado 80 en el directorio actual y el test siempre es cierto. Hay que usar -gt o, mejor, (( )).
3. rm -rf /opt/tramontana/releases/* borra todo, incluido el release activo al que apunta el enlace app: la aplicación se cae en el acto.
4. echo ... && rm ... || echo "error". Si el rm falla parcialmente se imprimen ambos mensajes y el script no devuelve ningún código útil. Además no hay --dry-run ni registro de qué se borró.

La lógica destructiva se delega en purgar_releases.sh, que ya sabe qué conservar, tiene --dry-run y registra lo que hace. Reutilizar en vez de reescribir es también una estructura de control.

Ya no escribes condicionales por imitación: sabes qué ocurre por debajo.

• Tienes claro que la condición es un código de salida, que 0 es éxito, y que cualquier comando —incluida una función tuya— puede ir en un if.
• Usas if/elif/else ordenando de la condición más restrictiva a la más laxa, y eliges entre los tres tipos de test: [[ ]] por defecto porque no divide palabras y admite patrones, (( )) para lo numérico, y [ ] solo si necesitas POSIX.
• Manejas la tabla completa de operadores de fichero, cadena y número; no confundes -eq con == ni entrecomillas el lado derecho de un patrón; validas con =~ y BASH_REMATCH, con la regex sin comillas y anclada con ^ y $; y escribes case con patrones de globbing, el *) obligatorio y los terminadores ;;, ;& y ;;&.
• Recorres con for sobre globs, nunca sobre $(ls), con la forma aritmética cuando el índice importa, y con while/until para esperas y lecturas; controlas el flujo con break N, continue N y select. Conoces la trampa de cond && accion || otra y la regla de rendimiento: si el bucle procesa texto, probablemente quieres awk, medido en un caso real.
• Y tus scripts deciden: revision_salud.sh devuelve OK, AVISO o CRÍTICO con códigos aptos para monitorización, y purgar_releases.sh recorre los releases conservando el activo, el anterior y los más nuevos.

Mira ahora los scripts juntos: log() está copiada tres veces, error() también, el envoltorio ejecutar() va por su segunda copia y el bloque de getopts es casi idéntico en todos. Cada vez que mejores uno tendrás que acordarte de mejorar los demás, y algún día no te acordarás. En la siguiente lección, Funciones y Librerías, resolvemos eso: cuándo extraer una función y por qué el nombre es documentación, el ámbito dinámico de Bash y por qué toda variable debe ser local, las tres formas reales de devolver datos cuando return solo admite un número de 0 a 255, y cómo montar lib/comunes.sh con carga robusta, guardas de inclusión y hasta un pequeño test que compruebe que la librería funciona. Al terminarla, esas funciones duplicadas vivirán en un solo sitio.