Portes cinc lliçons escrivint set -euo pipefail sense saber què fa. Has posat dues vegades un return 0 al final de log() «perquè si no, l'script mor». I informe_reserves.sh crea el directori de l'informe i, si alguna cosa falla a mig escriure'l, deixa un fitxer incomplet que demà algú llegirà com si fos bo. Tot això s'arregla avui, i convé entendre per què importa tant: un script que es trenca aviat i fa soroll és infinitament millor que un que falla a mitges en silenci. El primer et desperta a les quatre de la matinada amb un missatge clar; el segon et deixa una còpia truncada que descobriràs el dia que la necessitis. Aquesta lliçó va d'aconseguir el primer: veure què fa el teu script, fer que s'aturi quan cal i garantir que deixa les coses netes passi el que passi. Al final escriurem per fi copia_tramontana.sh.

1. Depuració: veure què fa realment l'script
2. shellcheck seriosament
3. El mode estricte esmicolat
4. On set -e no et salva
5. trap i els pseudosenyals
6. Neteja garantida i Ctrl+C
7. Un gestor ERR que serveixi d'alguna cosa
8. Idempotència
9. Reintents, temporals segurs i bloqueig
10. Aplicació: copia_tramontana.sh

bash -x és l'eina principal, i la seva sortida per defecte (+ ordre) és poc útil tan bon punt hi ha funcions. Amb un PS4 decent canvia completament:

Cada línia diu ara fitxer, número de línia i funció, i mostra l'ordre després d'expandir variables: veus basename /opt/tramontana/releases/3.2.1, no basename "$(readlink -f "$BASE/app")". Aquella diferència és justament el que busques quan una variable no val el que et pensaves. Traçar un script sencer genera centenars de línies, així que per acotar envolta només la zona sospitosa amb set -x … set +x. Exporta a més el PS4 al teu ~/.bashrc per no escriure'l cada vegada. set -v es fa servir molt menys, però és el complement de -x quan el problema és a l'expansió mateixa: -v ensenya el que vas escriure i -x el que Bash va entendre.

Ja el vas instal·lar a 04-01. Aquests són els avisos que més veuràs, amb el seu perquè:

SC2155 mereix demostració, perquè és subtil i apareix a tot arreu:

Al primer l'error de false desapareix i, amb set -e, l'script continua alegrement amb una variable buida; al segon es detecta. La regla: declara primer, assigna després.

Silenciar un avís és legítim quan saps què fas, però sempre amb justificació escrita, i la directiva afecta només la línia següent (si la poses al principi del fitxer silencia l'avís a tot l'script, cosa que gairebé mai no és el que vols):

set -euo pipefail són tres ajustos independents, i convé saber exactament què fa cadascun.

• set -e (errexit): si una ordre retorna un codi diferent de 0, l'script acaba immediatament amb aquell codi. Converteix les fallades silencioses en aturades sorolloses.
• set -u (nounset): fer servir una variable no definida és un error fatal en comptes d'expandir-se a la cadena buida. Evita el clàssic rm -rf "$DIR/" convertit en rm -rf / perquè DIR no existia.
• set -o pipefail: una canonada retorna el codi de l'últim tram que ha fallat, no el de l'últim tram; sense això, cat inexistent | wc -l retorna 0 i el teu script creu que tot ha anat bé.

Sobre set -u, dos detalls pràctics. Amb Bash 4.4 i posteriors —inclòs el 5.2 del teu Ubuntu 24.04— "$@" i "${matriu[@]}" buits ja no disparen l'error, però ${matriu[0]} d'una matriu buida sí. I la sortida d'emergència per a qualsevol variable que legítimament pugui no existir és ${VAR:-}, que ja fas servir des de 04-02: [[ -n ${TRAMONTANA_VERBOSE:-} ]] && echo "mode detallat".

Aquest és el material que gairebé ningú no explica i que fa que la gent confiï de més en el mode estricte. set -e es desactiva en cinc contextos, i en tots ells una fallada passa desapercebuda:

El cas 4 és el més traïdor i mereix veure's funcionant:

cp va fallar, set -e estava actiu, i la funció va continuar fins al final i va declarar èxit, perquè en fer-la servir com a condició Bash desactiva errexit a tot el seu cos. S'arregla comprovant a dins (cp ... || return 1) o no fent servir la funció com a condició: cridar-la solta i deixar que set -e faci la seva feina. La conclusió pràctica: set -e és una xarxa de seguretat, no un pla. Comprova explícitament el que importa —amb || morir, amb if— i deixa que set -e atrapi el que s'escapi. I suma-hi el parany de 04-02: (( i++ )) amb i a 0 retorna 1 i sí que avorta; fes servir (( ++i )) o i=$(( i + 1 )).

trap instal·la un gestor que s'executa en arribar un senyal. La seva sintaxi és trap 'ordres' SENYAL... i, a més dels senyals de 03-06, admet quatre pseudosenyals:

EXIT és l'important: és l'única manera de garantir que una cosa passi passi el que passi, perquè es dispara amb un exit normal, amb una fallada de set -e, amb un Ctrl+C i amb un kill; només SIGKILL se'l salta, i contra això no hi ha defensa. Tres detalls que eviten sorpreses: les cometes del gestor decideixen quan s'expandeixen les variables (simples, en el moment del dispar, que gairebé sempre és el que vols); trap - EXIT desinstal·la un gestor; i trap -p llista els instal·lats.

El patró que converteix un script en una cosa segura d'interrompre:

Quatre decisions deliberades. local codi=$? va a la primera línia, perquè qualsevol ordre anterior el sobreescriuria. La comprovació [[ -n $TEMPORAL && -d ... ]] protegeix del cas en què l'script mori abans de crear el temporal: sense ella, un rm -rf "$TEMPORAL"/* amb la variable buida seria catastròfic. exit "$codi" preserva el codi original en comptes de retornar el del rm. I el gestor d'INT surt amb 130, que és 128 + 2 (SIGINT), la convenció de 04-01; aquell exit 130 dispara al seu torn l'EXIT, així que la neteja s'executa igualment: els gestors s'encadenen, no es trepitgen.

Bash publica quatre variables durant un gestor ERR, i amb elles es construeix una traça gairebé tan útil com la d'un llenguatge amb excepcions:

En quatre línies saps el codi, el fitxer, la línia, l'ordre exacta ja expandida i la cadena de crides. Compara-ho amb el cp: Permission denied a seques que hauries tingut i entendràs per què aquesta funció mereix viure a lib/comuns.sh.

Un script és idempotent si executar-lo dues vegades deixa el sistema igual que executar-lo una. És l'objectiu de disseny més valuós del mòdul, perquè significa que el pots rellançar després d'una fallada sense pensar-hi. El contraexemple canònic, que en Luis va escriure el mes passat:

Després de quatre execucions, grep -c '^max_connexions=' /etc/tramontana/app.conf retorna 4. L'aplicació llegeix l'última i funciona, així que ningú no se n'assabenta... fins que algú edita la primera i no passa res. La versió idempotent comprova abans d'actuar:

Tres idees transferibles: mkdir -p en comptes de mkdir (no falla si existeix), ln -sfn en comptes de ln -s (reemplaça l'enllaç en comptes d'imbricar-lo a dins) i comprovar l'estat desitjat abans d'aplicar el canvi. És el model amb què treballa Ansible, i per això la seva sortida distingeix ok de changed; hi tornarem a 07-06.

Una operació de xarxa no falla: falla de vegades. Reintentar immediatament empitjora les coses, així que s'espera cada vegada més:

Les esperes van 2, 4, 8, 16: això és el retrocés exponencial. I no reintentis mai operacions no idempotents —crear una reserva, enviar un correu— sense un identificador que eviti duplicar-les.

TMP="/tmp/copia_$$" és un forat de seguretat real: el PID és predictible, així que un atacant pot crear per endavant un enllaç simbòlic amb aquell nom apuntant a /etc/tramontana/app.conf, i el teu script, si corre amb privilegis, sobreescriurà el fitxer apuntat. TMP=$(mktemp -d) || morir 73 "sense temporal" ho evita perquè crea el fitxer de manera atòmica (amb O_EXCL, que falla si ja existeix), amb nom aleatori i permisos 600 —700 per a directoris—. Fes-lo servir sempre, juntament amb el trap ... EXIT de l'apartat 6.

A 03-07 vas posar flock -n davant de l'ordre a la línia de crontab. Millor que el bloqueig visqui dins de l'script, perquè protegeixi també quan el llancis a mà:

exec 9>"$BLOQUEIG" || morir 73 "no puc obrir el bloqueig" seguit de flock -n 9 || morir 75 "ja hi ha una altra còpia en marxa". exec 9>fitxer obre el descriptor 9 per a tot l'script i flock -n 9 intenta bloquejar-lo sense esperar. El bloqueig s'allibera sol quan el procés mor, fins i tot a cop de kill -9, perquè el manté el nucli i no el fitxer. No esborris el fitxer de bloqueig en acabar: obre una cursa en què dos processos podrien bloquejar fitxers diferents amb el mateix nom.

Promès des del Mòdul 2, amb tot el d'aquesta lliçó:

Prova també el camí de fallada, que és on l'script demostra el seu valor: interromp-lo amb Ctrl+C a mitges i comprova que no queda cap .copia.XXXXXXXX ni cap .parcial al destí. La neteja que no has provat és neteja que no funciona.

• Creure que set -e ho atura tot. No actua en condicions, ni després de &&/||, ni dins de funcions fetes servir com a condició, ni a local x=$(cmd): continua comprovant l'important a mà.
• No capturar $? a la primera línia del gestor EXIT. Qualsevol ordre anterior el sobreescriu i l'script retorna 0 encara que hagi fallat.
• Fer servir cometes dobles al gestor de trap. Les variables s'expandeixen en instal·lar la trampa, no en disparar-la: cometes simples tret que sàpigues per què. I no esborris el fitxer de bloqueig en acabar, perquè obre una cursa entre processos: el bloqueig l'allibera el nucli en morir el procés.
• mktemp sense trap ... EXIT. Cada execució fallida deixa brossa: van sempre junts. Evita també els noms predictibles a /tmp, perquè $$ no és aleatori: és un atac d'enllaços simbòlics esperant l'ocasió.
• Scripts no idempotents. Si rellançar-lo duplica una línia o suma dues vegades, no pots reintentar després d'una fallada, que és justament quan més falta fa.
• Consell: escriu el fitxer definitiu amb un nom temporal i reanomena'l al final; és la manera barata que mai no existeixi un fitxer a mitges. I quan una cosa no funcioni, bash -x amb PS4 abans de rellegir el codi: cinc segons de traça estalvien vint minuts de suposicions.
• Consell: prova el camí d'error, no només el d'èxit: treu permisos, omple el disc, mata el procés a mitges. És l'única manera de saber si les teves trampes funcionen.

Exercici 1. Aquest script sembla correcte i falla en silenci. Explica per què i arregla'l de dues maneres.

Exercici 2. Afegeix a lib/comuns.sh una funció amb_neteja: ha de crear un directori temporal, publicar-lo a TRAMONTANA_TMP, instal·lar el trap de neteja i retornar 0. Escriu un cas de prova que verifiqui que, després d'un script que mor per set -e, el directori ja no existeix.

Exercici 3. Fes idempotent aquest fragment de desplegament d'en Luis i explica quin problema resol cada canvi: mkdir /opt/tramontana/releases/3.3.0, tar -xzf /tmp/app-3.3.0.tar.gz -C /opt/tramontana/releases/3.3.0, ln -s /opt/tramontana/releases/3.3.0 /opt/tramontana/app i echo "3.3.0" >> /opt/tramontana/HISTORIAL.

Solució 1. La fallada és el cas 4 de l'apartat 4: preparar_desti es fa servir com a condició d'un if, i això desactiva set -e a tota la funció. El cp falla, imprimeix el seu error, l'execució continua, s'imprimeix «destí preparat», la funció retorna 0 —el codi de l'echo— i l'if dona el resultat per bo. L'script anuncia que comença la còpia amb el destí incomplet.

L'arranjament A és preferible quan la funció pot fallar de maneres que vols distingir; el B, quan qualsevol fallada ha d'avortar. El que no val és l'original, que promet comprovar i no comprova.

Solució 2.

La prova importa perquè la funció depèn de dues subtileses fàcils de trencar: les cometes simples del trap i el fet que EXIT es dispari també quan qui mata l'script és set -e. Un test ho fixa; un comentari no.

Solució 3.

Els quatre canvis. mkdir -p evita que la segona execució mori a la primera línia. El tar -tzf previ detecta un paquet truncat abans d'haver tocat res. ln -sfn arregla l'error clàssic: ln -s sobre un enllaç que ja apunta a un directori crea el nou enllaç dins d'aquell directori, deixant /opt/tramontana/releases/3.2.1/3.3.0, i el desplegament no canvia res mentre tu creus que sí. I el grep -qxF —-x línia completa, -F text literal— converteix el >> en condicional, evitant un HISTORIAL amb la mateixa versió repetida quatre vegades.

Els teus scripts ja no fallen en silenci, i per primera vegada els pots interrompre sense por.

• Depures amb bash -x i un PS4 que diu fitxer, línia i funció, acotant zones amb set -x/set +x, i comproves la sintaxi sense executar amb bash -n. Entens SC2086, SC2046, SC2164 i SC2155, i saps silenciar un avís justificant-lo a la línia anterior.
• Coneixes el mode estricte peça a peça —-e, -u, pipefail— i, sobretot, els cinc contextos on set -e no actua, amb el cas de la funció feta servir com a condició demostrat i arreglat de dues maneres. Fas servir trap amb EXIT, ERR i INT, capturant $? a la primera línia del gestor, amb cometes simples, sabent que EXIT es dispara passi el que passi tret d'amb SIGKILL.
• Escrius un traca_error() que aprofita BASH_COMMAND, BASH_LINENO i FUNCNAME per donar una traça de debò, i dissenyes per a la idempotència: mkdir -p, ln -sfn, comprovar abans d'afegir, escriure a .parcial i reanomenar al final.
• Reintentes amb retrocés exponencial, crees temporals amb mktemp en comptes de noms predictibles amb $$, i bloqueges amb flock sobre un descriptor dins del mateix script.
• I copia_tramontana.sh existeix per fi: amb bloqueig, temporals que es netegen sols, escriptura atòmica, suma de verificació, permisos 640 sobre un arxiu que conté db_password i codis de sortida documentats.

Queda una última pregunta, la que separa un script que funciona d'un que es desplega: què passa quan això ho executi cron a les 4:20 sense ningú al davant? On va el registre? Com s'avisa la Marta només si hi ha alguna cosa a fer? D'on surt la contrasenya de la base de dades si no pot ser al fitxer? I què passa si una execució triga més que l'interval entre execucions? A Scripts de Producció: Bones Pràctiques tanquem el mòdul amb aquella llista de comprovació completa, la plantilla canònica amb main "$@", la precedència de configuració implementada de debò, el principi de «silenci si tot va bé», les proves abans de producció, i el projecte integrador: desplegar.sh, amb validació, còpia prèvia, canvi atòmic de l'enllaç, comprovació per curl i reversió automàtica si el 8080 no respon.