A les tres lliçons anteriors has escrit if, case i [[ ]] guiant-te per la semblança amb altres llenguatges. Funcionava, però no sabies per què. Toca arreglar-ho començant per la idea que en Bash ho governa tot i que gairebé cap tutorial no enuncia amb claredat: aquí no es ramifica segons un valor booleà, es ramifica segons el codi de sortida d'una ordre. if no espera una expressió: espera una ordre, l'executa i mira si ha retornat 0; tota la resta —[ ], [[ ]], (( ))— són ordres que existeixen per produir aquell 0 o 1. Amb aquella peça al seu lloc, la resta encaixa sola. Al final, revisio_salut.sh sabrà dir OK, AVÍS o CRÍTIC, i naixerà purgar_releases.sh.

1. La condició és un codi de sortida
2. if, elif, else
3. Els tres tipus de test i quin fer servir
4. Taula completa d'operadors
5. Expressions regulars amb =~ i BASH_REMATCH
6. case i els seus tres terminadors
7. Bucles: for, while, until
8. break, continue i select
9. Curtcircuits && i ||, i el seu parany
10. Bucles i rendiment: quan vols awk
11. Aplicació: nivells d'alerta i purgar_releases.sh

No hi ha cap == true enlloc. if va executar grep -q, grep va retornar 0 perquè va trobar coincidències, i 0 significa èxit, així que es va entrar al then. Si no hagués trobat res hauria retornat 1 i s'hauria saltat el bloc.

Tres conseqüències que convé tenir presents des d'ara:

• Qualsevol ordre pot ser una condició: if ping -c1 -W2 10.0.2.15, if [[ -f fitxer ]], if la_meva_funcio. Totes són el mateix. I el [ clàssic és una ordre de debò, amb el seu executable a /usr/bin/[; per això [ $a = $b ] necessita espais: són arguments separats.
• La lògica està invertida respecte als llenguatges amb booleans: 0 és cert. Si escrius una funció que comprova alguna cosa, ha de retornar 0 quan la resposta és «sí».

La sintaxi exigeix then i fi; el ; abans de then permet posar-lo a la mateixa línia. Els elif s'avaluen en ordre i el primer que encerta guanya, així que les condicions van de la més restrictiva a la més laxa: si intercanviessis els dos primers blocs, un disc al 95 % diria AVÍS. Per negar, ! al davant: if ! systemctl is-active --quiet tramontana; then .... I compte amb if [ $? -eq 0 ], gairebé sempre redundant: posa l'ordre directament al if.

La diferència entre [ ] i [[ ]] no és cosmètica. [[ ]] és sintaxi del mateix shell, no una ordre, així que Bash no divideix en paraules ni expandeix globs a dins:

Amb [ ] la variable sense cometes es va partir en dos arguments i l'ordre ni tan sols va poder avaluar-se. Amb [[ ]] no cal entrecometar, i a més admet &&, ||, patrons i =~, que [ ] no té. Per a números, (( )) és molt més llegible: compara if (( errors > 20 && connexions >= 200 )) amb [ "$errors" -gt 20 -a "$connexions" -ge 200 ]. Recorda de 04-02 que dins de (( )) les variables van sense $.

La confusió clàssica mereix un avís en negreta: -eq és per a números i == per a cadenes. [[ "01" -eq "1" ]] és cert (numèricament iguals) però [[ "01" == "1" ]] és fals (cadenes diferents). Fer servir l'operador equivocat dona resultats correctes durant mesos i després falla amb un zero a l'esquerra o amb una versió com ara 3.10.

Un altre detall que sorprèn: dins de [[ ]], el costat dret de == no s'entrecometa si vols que sigui un patró:

Les cometes converteixen el patró en text literal: és la font número u de «la meva comparació no funciona i no sé per què».

=~ compara amb una expressió regular estesa (l'ERE de 03-02) i, a més de dir sí o no, deixa les captures a la matriu BASH_REMATCH: la posició 0 és la coincidència completa i les següents, els grups entre parèntesis.

Amb això valides la columna data de reserves.csv abans de fiar-te'n. Dues regles d'or: la regex no va entre cometes —si l'entrecometes es torna text literal, igual que amb ==— i si la guardes en una variable, fes-la servir també sense cometes: [[ $f =~ $PATRO ]].

case compara una cadena contra patrons de globbing —no expressions regulars— i executa la primera branca que hi encaixi.

L'ordre importa: 404 va abans que 4* perquè guanya el primer que hi encaixa. | separa alternatives i *) és el cas per defecte, que va l'últim i convé posar sempre. Els tres terminadors:

;;& és rar però útil per a etiquetes acumulatives; ;& és perillós perquè un lector distret no el veu. Fes-los servir només amb un comentari que ho justifiqui.

La segona forma —iterar sobre un glob— és la correcta per recórrer fitxers, i porta dos avisos. El primer: si el glob no troba res, Bash deixa el patró literal i el bucle s'executa una vegada amb /var/log/tramontana/*.log com a valor; d'aquí el [[ -e ... ]] || continue, o bé shopt -s nullglob de 03-02. El segon, més important:

No escriguis mai for f in $(ls).

Ho veuràs a internet constantment i està malament per tres motius acumulatius: ls retorna text que el shell parteix per espais, així que «informe agost.txt» es converteix en dos elements; els caràcters especials del nom s'expandeixen com a globs; i ls pot acolorir o alinear segons opcions i àlies. El glob no té cap d'aquells problemes perquè Bash treballa amb noms de fitxer reals, no amb text. I existeix la forma aritmètica, for (( i = 0; i < ${#versions[@]}; i++ )), per a quan l'índex importa.

while repeteix mentre la condició retorni 0; until repeteix fins que retorni 0. Són la mateixa estructura amb la condició negada, i until guanya quan la frase natural és «espera fins que»:

Aquell bucle és el que necessita un desplegament per esperar que el servei estigui a punt, i el reutilitzarem a 04-07. Ja coneixes a més el while read de 04-03, que és el tercer ús habitual.

break surt del bucle i continue salta a la iteració següent. Tots dos accepten un número que indica quants nivells afecten: break 2 surt de dos bucles imbricats de cop.

Si et trobes amb tres nivells d'imbricació, això no és un problema de bucles: és una funció que encara no has escrit, i ho veurem a 04-05. Quant a select, és un bucle i sense break no acaba mai; PS3 és el text de l'avís i $REPLY guarda el que va teclejar l'usuari.

Ja els fas servir des de 02-01: A && B executa B només si A ha tingut èxit; A || B executa B només si A ha fallat. Com a condicional d'una línia són insuperables: [[ -d $DIR ]] || mkdir -p "$DIR", o command -v shellcheck >/dev/null || { echo "falta shellcheck" >&2; exit 69; }. Però molta gent escriu condicio && accio || altra_cosa creient que és un if/else, i no ho és:

La clau: || no mira la condició, mira el resultat de l'acció anterior. Si l'acció falla per qualsevol motiu —un mkdir sense permís, un grep sense coincidències— la branca del || s'executa a més de la del &&. La regla: encadena && i || només quan l'acció no pugui fallar; tan bon punt hi hagi un else de debò, fes servir if.

Aquest apartat t'estalviarà hores d'espera. Comptem les 14 respostes 500 d'acces.log de dues maneres:

Tres-centes vegades més ràpid, i només amb 412 línies. La causa no és que Bash interpreti a poc a poc: és que el bucle llança un procés grep per cada línia, i crear un procés costa uns mil·lisegons que es multipliquen. Amb les 10.000 línies que tindrà acces.log en un mes, el bucle trigaria gairebé un minut i awk continuaria en centèsimes. La regla:

• Si el bucle processa text línia a línia, probablement vols awk (o grep, sed, sort), que fan una sola passada dins d'un únic procés.
• Si el bucle ha de cridar una ordre externa a cada volta —curl, systemctl, tar— aleshores sí que és feina de Bash, perquè no hi ha alternativa. I si necessites Bash sobre text, almenys no llancis processos a dins: read amb diversos noms, case i expansió de paràmetres fan molt sense sortir del shell.

revisio_salut.sh per fi decideix. Substituïm el bloc d'impressió per comprovacions amb nivell:

Amb aquells codis —0 correcte, 1 avís, 2 crític— l'script ja serveix per a monitoració: Nagios, Zabbix i companyia fan servir exactament aquella convenció. I l'script nou:

Just el que volíem: només 3.1.0 és purgable. Fixa't en dos detalls defensius: rm -rf -- "${DIR_RELEASES:?}/$v" fa servir ${VAR:?} de 04-02 perquè, si la variable quedés buida per un error, l'ordre avorti en comptes de convertir-se en rm -rf /; i -- evita que un nom de directori amb guionet inicial es llegeixi com a opció.

• Oblidar els espais dins de [ ] o [[ ]]. [[$a == $b]] dona command not found: els claudàtors són ordres i paraules reservades, no sintaxi enganxada.
• Barrejar -eq amb cadenes o == amb números. [[ "3.10" > "3.9" ]] és fals lexicogràficament: per a versions, sort -V; per a números, (( )). I no entrecometis el costat dret de == o =~, o el patró es torna text literal.
• for f in $(ls). Es trenca amb espais i amb caràcters especials; fes servir sempre el glob. I protegeix el glob sense coincidències amb [[ -e $f ]] || continue o shopt -s nullglob, o el bucle correrà una vegada amb el patró literal.
• Confiar en cond && accio || altra com a if/else. Si accio falla, s'executen les dues branques. I imbricar tres bucles és el senyal inequívoc que falta una funció.
• Consell: compara números sempre amb (( )): és més llegible i no confondràs l'operador. Posa sempre la branca *) en un case, encara que només sigui per registrar «valor inesperat». I abans d'escriure un bucle que processi text, pregunta't si awk ho faria d'una passada: gairebé sempre la resposta és sí.

Exercici 1. Escriu es_versio_valida(), que retorni 0 si el seu argument té el format N.N.N (un o més dígits per tram) i 1 si no, fent servir =~, i que imprimeixi els tres números per separat. Prova-la amb 3.2.1, 3.10.0, 3.2 i v3.2.1.

Exercici 2. Escriu ~/scripts/resum_franges.sh, que sobre acces.log classifiqui cada petició en matinada (00-05), matí (06-13), tarda (14-21) o nit (22-23) amb case, i mostri peticions i errors per franja. Fes-ho sense llançar processos dins del bucle i compara el temps amb awk.

Exercici 3. En Luis ha escrit aquest fragment per decidir si cal purgar. Troba-hi els quatre defectes i reescriu-lo.

Solució 1.

Els punts van escapats (\.) perquè en una regex . significa «qualsevol caràcter»; sense escapar, 3x2y1 també seria vàlida. I fixa't en com la funció es fa servir directament al if: és l'apartat 1 en acció. (Sense return 0 explícit, la funció retorna el codi del printf, que és 0.)

Solució 2.

Els 15 errors de matinada són els de la franja de les 03:00 que ja coneixes, i els 23 totals quadren. La versió en awk —una línia amb substr($2,1,2)+0 i el ternari per a la franja— triga 0,007 s: set vegades menys tot i no haver-hi processos dins del bucle, només pel cost de l'intèrpret. Però fixa't en l'escala: centèsimes contra centèsimes. La diferència catastròfica apareix quan hi ha $(...) dins del bucle, no pel bucle en si. I nota el patró [45]* del case: globbing, no regex.

Solució 3. Els quatre defectes:

1. ` ` en comptes de $( ). Les cometes invertides no s'imbriquen, tenen regles d'escapament diferents i són il·legibles. A més $5 de df inclou el %, així que la comparació numèrica rep 30%.
2. [ $lliure > 80 ]. Dins de [ ], > no compara: és una redirecció, així que aquella ordre crea un fitxer anomenat 80 al directori actual i el test sempre és cert. Cal fer servir -gt o, millor, (( )).
3. rm -rf /opt/tramontana/releases/* esborra tot, inclòs el release actiu al qual apunta l'enllaç app: l'aplicació cau a l'acte.
4. echo ... && rm ... || echo "error". Si el rm falla parcialment s'imprimeixen tots dos missatges i l'script no retorna cap codi útil. A més no hi ha --dry-run ni registre de què s'ha esborrat.

La lògica destructiva es delega a purgar_releases.sh, que ja sap què conservar, té --dry-run i registra el que fa. Reutilitzar en comptes de reescriure també és una estructura de control.

Ja no escrius condicionals per imitació: saps què passa per sota.

• Tens clar que la condició és un codi de sortida, que 0 és èxit, i que qualsevol ordre —inclosa una funció teva— pot anar en un if.
• Fas servir if/elif/else ordenant de la condició més restrictiva a la més laxa, i tries entre els tres tipus de test: [[ ]] per defecte perquè no divideix paraules i admet patrons, (( )) per al que és numèric, i [ ] només si necessites POSIX.
• Maneges la taula completa d'operadors de fitxer, cadena i número; no confons -eq amb == ni entrecometes el costat dret d'un patró; valides amb =~ i BASH_REMATCH, amb la regex sense cometes i ancorada amb ^ i $; i escrius case amb patrons de globbing, el *) obligatori i els terminadors ;;, ;& i ;;&.
• Recorres amb for sobre globs, mai sobre $(ls), amb la forma aritmètica quan l'índex importa, i amb while/until per a esperes i lectures; controles el flux amb break N, continue N i select. Coneixes el parany de cond && accio || altra i la regla de rendiment: si el bucle processa text, probablement vols awk, mesurat en un cas real.
• I els teus scripts decideixen: revisio_salut.sh retorna OK, AVÍS o CRÍTIC amb codis aptes per a monitoració, i purgar_releases.sh recorre els releases conservant l'actiu, l'anterior i els més nous.

Mira ara els scripts junts: log() està copiada tres vegades, error() també, l'embolcall executar() va per la seva segona còpia i el bloc de getopts és gairebé idèntic a tots. Cada vegada que en milloris un t'hauràs de recordar de millorar els altres, i algun dia no te'n recordaràs. A la lliçó següent, Funcions i Biblioteques, resolem això: quan extreure una funció i per què el nom és documentació, l'àmbit dinàmic de Bash i per què tota variable ha de ser local, les tres formes reals de retornar dades quan return només admet un número de 0 a 255, i com muntar lib/comuns.sh amb càrrega robusta, guardes d'inclusió i fins i tot un petit test que comprovi que la biblioteca funciona. En acabar-la, aquelles funcions duplicades viuran en un sol lloc.