Al cerrar 05-02 quedó identificado el agujero que sigue teniendo informe-diario.sh: si algo falla dentro, el script no se entera. Bash, por diseño, ejecuta la línea siguiente pase lo que pase con la anterior. Si el grep sobre el CSV no encuentra nada, si una variable está mal escrita y se expande a la cadena vacía, si el disco se llena a media escritura, el script sigue adelante y produce un informe silenciosamente falso —lo peor que puede hacer una herramienta de operaciones, porque nadie sospecha de un número equivocado que llega puntual cada mañana—. Y además deja atrás el temporal de mktemp que en 05-01 prometimos aprender a limpiar. Esta lección le da a Bash la disciplina que no trae de serie, y te da a ti las herramientas para ver qué está pasando cuando algo no cuadra.

1. El fallo silencioso
2. set -e: qué detecta y qué no
3. set -u: variables no definidas
4. set -o pipefail y PIPESTATUS
5. set -euo pipefail y su crítica honesta
6. trap: señales y pseudoseñales
7. Limpieza garantizada con EXIT
8. morir() y trap ... ERR con contexto
9. Convenio de códigos de salida
10. Reintentos con retroceso
11. Depuración: -n, -x, PS4, -v, DEBUG y bisección
12. informe-diario.sh endurecido

Ese ejemplo, con variantes, ha destruido servidores de verdad. Bash reporta el error en stderr y continúa. Contra eso hay tres interruptores.

set -e (o set -o errexit) hace que el script termine en cuanto un comando devuelva un código distinto de cero: con él al principio, el ejemplo anterior muere en el cd y nunca llega al rm. Lo importante es saber qué no detecta, porque las excepciones son muchas y deliberadas: un comando cuyo fallo forme parte de una decisión no debe matar el script.

Las dos últimas filas son las que más quebraderos dan. La de local tiene solución: declara y asigna en líneas separadas (local fecha y luego fecha=$(date -d "$1" +%F)), y así el fallo sí se detecta. Y la penúltima —una función pierde set -e en su interior cuando se llama desde un if o desde un &&— es la razón principal por la que hay quien desconfía de set -e. No es un error de Bash: es POSIX. Pero significa que no puedes delegar toda tu gestión de errores en -e.

Bajo set -u, un echo "Informe de $CIUDADD" con la variable mal escrita aborta con bash: CIUDADD: variable sin asignar. Sin -u, esa errata se expande a la cadena vacía y produce rm -rf "$DIR_BASE/" con DIR_BASE vacío, es decir rm -rf /. Convive perfectamente con los valores por defecto de 03-06, que son la forma explícita de decir "esta puede no existir":

Cuidado con los arrays: bajo -u y en Bash anterior a 4.4, "${arr[@]}" sobre un array vacío aborta. El idioma seguro es "${arr[@]:-}" o comprobar antes con (( ${#arr[@]} > 0 )).

En 02-04 quedó aplazado esto: el código de salida de una tubería es el de su último comando.

Un fallo así en informe-diario.sh produce "0 errores hoy" cuando la verdad es "no pude leer el fichero". pipefail lo arregla: la tubería devuelve el código del último comando que falló, o 0 si ninguno falló. Cuando necesitas saber cuál de los eslabones falló, el array PIPESTATUS guarda todos los códigos, en orden:

PIPESTATUS se sobrescribe con cada comando, incluido un echo. Si vas a usarlo, cópialo primero: local -a codigos=( "${PIPESTATUS[@]}" ).

La cabecera que verás en casi todo script serio es set -euo pipefail justo bajo el shebang, a veces acompañada de un IFS=$'\n\t' restrictivo (03-06). Es un buen valor por defecto y deberías usarlo. Pero conviene decir con claridad por qué no es magia:

• set -e tiene el agujero de las funciones llamadas desde if, así que las funciones críticas deben comprobar sus propios errores.
• Aborta con un mensaje del comando que falló, sin decir en qué línea de tu script ocurrió. Eso lo arregla el trap ... ERR de la sección 8.
• Convierte cualquier código distinto de cero en fatal, y hay comandos donde eso es normal: grep sin coincidencias, diff con diferencias, pgrep sin procesos. Hay que marcarlos explícitamente.

Para esos casos, tres idiomas:

La regla: || true para el caso trivial, if ! cuando quieres reaccionar, y set +e/set -e acotado a las mínimas líneas posibles. Un set +e al principio de un script largo es peor que no haber puesto nunca -e, porque da falsa sensación de seguridad.

trap 'comandos' SEÑAL [SEÑAL...] registra código que se ejecuta cuando llega una señal. Sus variantes: trap - SEÑAL restaura el comportamiento por defecto, trap '' SEÑAL la ignora y trap -p lista las trampas activas.

Además de las señales reales de 05-02, Bash define cuatro pseudoseñales:

Usa comillas simples en el código de la trampa. trap 'rm -f "$tmp"' EXIT es correcto porque $tmp se resuelve al dispararse; con comillas dobles se expandiría al registrar la trampa y capturarías el valor equivocado.

Aquí se cierra lo prometido en 05-01 y 05-02:

EXIT se dispara con exit, al terminar la última línea, cuando set -e aborta y cuando llega una señal capturada. Dos detalles que la gente olvida: el local codigo=$? debe ser la primera línea de la función, porque cualquier comando anterior lo sobrescribe; y el exit "$codigo" final evita que la limpieza convierta un fallo en un éxito aparente. Para que Ctrl-C también pase por ella, añade las señales: trap limpiar EXIT INT TERM HUP.

Todo script serio tiene una función para abortar con mensaje. La convención: mensaje a stderr, código de salida significativo.

Y para los fallos que no previste, una trampa ERR que diga exactamente dónde ocurrió:

Las tres variables que dan el contexto son las que convierten un mensaje inútil en un diagnóstico:

FUNCNAME es un array: ${FUNCNAME[1]} es quien llamó a la función actual, y recorriéndolo junto con BASH_LINENO se imprime una traza de pila completa. Eso sí: para que la trampa ERR se herede dentro de funciones y subshells hace falta set -E (o set -o errtrace); sin él, las funciones no la disparan.

En 03-01 viste exit N. Ahora el convenio, que importa cuando otro script o cron lee tu resultado:

Los del rango 64-78 vienen de sysexits.h de BSD; no todo el mundo los usa, pero son mejor convenio que inventar números. Y la regla 128 + N para señales explica de un vistazo el 137 (128+9, SIGKILL) y el 143 (128+15, SIGTERM). Reserva los códigos por encima de 125 y no uses valores mayores de 255: se truncan módulo 256, así que exit 256 es exit 0.

Los fallos de red son transitorios por naturaleza: reintentar es correcto, pero reintentar de inmediato y sin límite es un ataque contra tu propio servidor. El patrón es retroceso exponencial:

Las esperas son 1, 2, 4, 8 segundos. Nótese la combinación con timeout de 05-02: sin él, un intento colgado impide llegar al siguiente. El uso real con curl y APIs llega en 06-04 y 06-05.

bash -n debería ser un reflejo antes de guardar cualquier script que vaya a cron: detecta el fi que falta sin ejecutar el rm. Y set -x / set +x acotan la traza a la parte sospechosa, que es lo que la hace usable en un script largo.

La traza sale a stderr precedida de +. Ese prefijo es la variable PS4, y enriquecerla convierte una traza ilegible en un diagnóstico:

La traza resultante tiene esta forma —+ informe-diario.sh:91:acumular_dia(): [[ 2026-08-03 == 2026-08-03 ]]—: cada línea dice fichero, línea y función. Y BASH_XTRACEFD la desvía a un fichero para que no se mezcle con la salida del informe (el descriptor 8 es de la familia que verás a fondo en 05-05). Por su parte, trap 'printf "línea %d: total=%s\n" "$LINENO" "${total:-}" >&2' DEBUG inspecciona el estado antes de cada comando, útil para cazar dónde cambia una variable.

Cuando nada de esto basta, queda la bisección: colocar exit 99 a mitad del script, ver si el problema aparece, mover el exit a la mitad de la mitad que corresponda y repetir. Con cinco o seis ejecuciones localizas la línea culpable de un script de mil. Y para prevenir en lugar de curar, shellcheck detecta estáticamente la mayoría de estos fallos antes de ejecutar nada: es el tema de 08-05.

Cuatro líneas de cabecera y dos trampas: el script ya no miente. Si el CSV no se puede leer, muere con 66 y un mensaje; si algo inesperado falla, dice fichero, línea y función; y el temporal se borra por las cuatro vías posibles de salida.

• Creer que set -e lo cubre todo. Las funciones llamadas desde if lo pierden. Comprueba también a mano.
• trap con comillas dobles. Las variables se expanden al registrar la trampa, no al dispararla.
• No capturar $? en la primera línea del manejador EXIT, u olvidar el exit "$codigo" final. Un fallo se convierte en éxito aparente y cron no avisa.
• trap ... ERR sin set -E. Las funciones no lo disparan y el diagnóstico no aparece nunca.
• Usar PIPESTATUS después de otro comando. Se sobrescribe con cada uno; cópialo de inmediato.
• exit 300. Se trunca módulo 256 y sale con 44. Mantente entre 0 y 125.
• Consejo: escribe la trampa de limpieza en la misma línea en que creas el temporal. Si lo dejas para "luego", el return temprano que añadas dentro de un mes se llevará el borrado por delante.

Ejercicio 1. Escribe una cabecera completa para un script archivar-historico.sh que use modo estricto, cree un directorio temporal, garantice su borrado también ante Ctrl-C, preserve el código de salida original e informe de la línea exacta ante cualquier fallo imprevisto.

Ejercicio 2. La función contar_errores() usa zgrep -c ERROR "$LOG" | tr -d ' '. Explica por qué bajo set -e sin pipefail puede devolver un número falso, y reescríbela para que distinga "cero errores" de "no pude leer el fichero", saliendo con 66 en el segundo caso.

Ejercicio 3. Añade a informe-diario.sh una opción --debug que active una traza enriquecida (fichero, línea y función) volcada a ~/veloz-ops/logs/traza-AAAA-MM-DD.log, sin ensuciar ni la salida del informe ni sus errores.

Solución 1.

-E es imprescindible para que la trampa ERR funcione dentro de funciones. INT TERM HUP junto a EXIT puede parecer redundante —una señal capturada acaba disparando EXIT—, pero explicitarlas garantiza el borrado también si alguien redefine el comportamiento por defecto.

Solución 2. Sin pipefail, el código de la tubería es el de tr, que siempre vale 0: si zgrep no pudo abrir el fichero, la función devuelve la cadena vacía como si fueran cero errores. Además, zgrep -c devuelve 1 cuando hay cero coincidencias, que bajo set -e mataría el script sin ser un error real.

La guarda [[ -r ]] separa el fallo real (fichero ilegible → código 66) del caso legítimo (cero errores → imprime 0). Es más claro que cualquier acrobacia con PIPESTATUS, y la lección es general: comprueba las precondiciones tú mismo en vez de deducirlas de códigos ambiguos.

Solución 3.

BASH_XTRACEFD=8 desvía la traza al descriptor 8, así que ni stdout (el informe) ni stderr (los avisos) se contaminan: puedes seguir canalizando el informe a un fichero mientras lees la traza en otra terminal con tail -f. El >> conserva las trazas de varias ejecuciones del mismo día.

Bash no aborta por su cuenta, así que la robustez se pide explícitamente. set -e mata el script al primer fallo, con excepciones deliberadas —condicionales, &&/||, negaciones, funciones llamadas desde if— que debes conocer para no confiarte; set -u convierte una errata en un error visible en lugar de en una cadena vacía peligrosa; set -o pipefail arregla el código de salida de las tuberías, y PIPESTATUS dice qué eslabón falló. La línea set -Eeuo pipefail es el punto de partida correcto, pero no una garantía: hace falta marcar con || true o if ! los comandos cuyo fallo es normal. trap completa el cuadro: EXIT da la limpieza garantizada que hace segura la pareja mktemp + borrado, y ERR con $LINENO, BASH_SOURCE y FUNCNAME convierte un error mudo en un diagnóstico con fichero, línea y función. Una morir() con códigos del convenio sysexits y un patrón de reintentos con retroceso completan el arsenal. Y para investigar: bash -n valida sintaxis, set -x con un PS4 enriquecido y BASH_XTRACEFD produce una traza legible y aislada, y la bisección con exit temporal localiza lo que se resista.

Queda una deuda pendiente desde el Módulo 2. El toolkit valida rutas, procesos y códigos, pero cuando tiene que validar texto —una fecha --fecha 2026-08-03, una IP, un código HTTP, la estructura de una línea de app.log— sigue recurriendo a comparaciones frágiles con globs. En 05-04 llegan por fin las expresiones regulares de verdad: los tres sabores y qué herramienta usa cada uno, la sintaxis desde cero, y el operador =~ de Bash con BASH_REMATCH, que valida y extrae en un solo paso.