En tancar el Mòdul 3 va quedar un mur assenyalat amb el dit: la línia de crontab plena d'escapaments, la canonada de l'informe que ja no cabia a la pantalla, i aquella dependència insuportable que tu te'n recordessis de cada pas a les tres de la matinada. Aquest mòdul enderroca aquell mur amb la idea més simple del món: un script no és res més que un fitxer de text amb les ordres que ja saps escriure.

No hi ha cap llenguatge nou per aprendre: grep, awk, find, curl i df continuen sent els mateixos. El que canvia és que deixen de viure a la teva memòria per viure en un fitxer amb nom, permisos, autor i data; un fitxer que es pot executar igual mil vegades i córrer sol mentre tu dorms. Aquesta lliçó munta els fonaments i acaba amb revisio_salut.sh, el primer script del fil conductor, que les sis lliçons següents aniran millorant.

1. Val la pena que això sigui un script?
2. Què és exactament un script
3. El shebang: qui interpreta el teu fitxer
4. Les tres formes d'executar un script
5. Permisos d'execució
6. On viuen els scripts i el PATH
7. Anatomia d'un script decent
8. Comentaris útils i comentaris inútils
9. Codis de sortida
10. Primer script real: revisio_salut.sh
11. Estil i eines: shellcheck i shfmt

Escriure un script té un cost: cal mantenir-lo, versionar-lo, documentar-lo i recordar que existeix. Abans d'obrir l'editor, situa el que vols fer en aquesta escala.

La regla pràctica: si ho has fet tres vegades a mà, o si ho executarà algú que no ets tu, o si ho executarà cron, és un script. Si a més comença a manejar dades imbricades o a parlar amb API JSON, l'alarma està sonant i toca mirar cap a Python; hi tornarem a 04-07. La revisió de salut que la Marta demana cada matí compleix els tres criteris alhora: és un script.

Un fitxer de text pla amb ordres que l'intèrpret llegeix i executa en ordre. No es compila, no s'enllaça, no genera binaris.

bash ha obert el fitxer, ha llegit la primera línia, l'ha executada com si tu l'haguessis teclejada, i ha passat a la segona. Aquesta equivalència total entre «el que teclejes» i «el que va en un script» és la raó que aquest mòdul et resulti natural: ja saps escriure el contingut, només faltava el recipient.

Si el fitxer s'executa per si mateix, el nucli necessita saber quin programa l'ha d'interpretar: ho diuen els dos primers caràcters, #!, seguits de la ruta de l'intèrpret. En executar ./script.sh, el nucli llegeix aquells bytes màgics i arrenca en realitat /bin/bash ./script.sh. Sense shebang el resultat depèn d'on siguis, així que no ho deixis mai a l'atzar.

En aquest curs farem servir #!/usr/bin/env bash: costa el mateix i t'estalvia el dia que executis l'script en un macOS on el Bash modern és a /opt/homebrew/bin/bash.

A Ubuntu i Debian, ls -l /bin/sh revela un enllaç a dash, un shell minúscul que implementa POSIX i res més. Es va triar així perquè els scripts d'arrencada són milers i dash els executa molt més ràpid. La conseqüència és que tot el que és específic de Bash falla:

El mateix fitxer, dos intèrprets, dos resultats. [[ ]] és de Bash, igual que les matrius, ${VAR^^}, local -n o <<<. I fixa't en el detall cruel: l'script no va fallar en escriure'l, va fallar en executar-se amb l'intèrpret equivocat, possiblement setmanes després i dins de cron. Si escrius #!/bin/sh, no facis servir res de Bash.

N'hi ha tres —bash script.sh arrenca un Bash nou que llegeix el fitxer, ./script.sh deixa que el nucli llegeixi el shebang, i source script.sh (o . script.sh, la forma POSIX) l'executa el shell actual— i la diferència no és cosmètica: canvia en quin procés s'executen les teves ordres.

La demostració clàssica, un script que canvia de directori:

L'script sí que va canviar de directori... en el seu propi procés, que ja no existeix. Un fill hereta una còpia de l'entorn del seu pare, però res del que el fill canviï no torna al pare: ni el directori, ni les variables, ni les funcions. És l'herència d'una sola direcció de 03-01; amb source no hi ha procés nou i per això el cd persisteix.

Dues regles pràctiques. Els scripts s'executen amb ./ o pel seu nom, l'única forma que respecta el shebang i la que farà servir cron. I source es reserva per a configuració i biblioteques de funcions, que és per al que el farem servir a 04-05. Un avís: com que source no crea cap procés, un exit 1 dins d'un fitxer que fas source al teu terminal et tanca la sessió. Li ha passat a tothom una vegada.

Un fitxer de text no és executable fins que li ho dius al sistema. Reprenent 02-07:

chmod +x respecta l'umask 027 del Mòdul 2: afegeix x a usuari i grup, no a altres; chmod 750 diu el mateix sense dependre de l'umask. Dos matisos: el bit x no significa «això és codi màquina» sinó «permet-me intentar executar-ho» —qui decideix com interpretar-ho és el shebang—, i bash script.sh funciona sense bit x perquè allà el fitxer només es llegeix, que és la manera còmoda de provar una cosa a mig escriure.

Teclejar /home/operador/scripts/revisio_salut.sh cada matí garanteix que ningú no el faci servir. La solució és el PATH, que ja vas disseccionar a 03-01.

Fem servir un enllaç simbòlic en comptes de moure el fitxer: el codi continua a ~/scripts (versionat a git, ja a 04-07) i ~/bin només publica un nom còmode, sense extensió i amb guionets, com les ordres d'Unix. Continua vigent la regla del Mòdul 3: . mai al PATH, perquè n'hi hauria prou que algú deixés un fitxer anomenat ls en un directori compartit perquè executessis el seu codi sense saber-ho.

Aquesta és la plantilla amb què començaràs tots els teus scripts a partir d'avui. Cada línia evita un problema concret que veuràs durant el mòdul.

• Capçalera. Nom, propòsit, autor, data i manera d'ús: quan d'aquí a vuit mesos trobis aquest fitxer a les quatre de la matinada, aquelles cinc línies valdran més que tota la resta.
• set -euo pipefail. El mode estricte: -e avorta si una ordre falla, -u avorta si fas servir una variable no definida, i pipefail fa que una canonada falli si falla qualsevol dels seus trams, no només l'últim (ho vam anunciar a 03-04). Posa-ho des d'avui a tot el que escriguis; el perquè detallat i —sobretot— on no funciona és el cor de 04-06.
• Constants en MAJÚSCULES, minúscules per a les variables de treball, i totes agrupades a dalt: canviar un llindar no ha d'obligar a llegir l'script sencer.
• exit 0 explícit. Sense ell, l'script retorna el codi de l'última ordre, que pot ser qualsevol cosa. exit 0 diu «he arribat fins aquí i tot ha anat bé», i això és el que llegeixen cron i la monitoració.

Tot el que segueix un # s'ignora fins al final de línia, tret del shebang. Però comentar molt no és comentar bé.

La regla: el codi diu què fa; el comentari diu per què. Si necessites un comentari per entendre què fa una línia, la solució sol ser reescriure-la o extreure-la a una funció amb bon nom (04-05).

Tot procés acaba retornant un enter de 0 a 255. Ja el coneixes com a $?; ara ets tu qui el produeix, i això canvia la responsabilitat: el codi de sortida és l'única part del teu script que un altre programa llegirà. La convenció és a l'inrevés del que és intuïtiu —0 és èxit— i té sentit: hi ha una sola manera d'encertar i moltes de fallar, cadascuna amb el seu número.

(I exit -1 acaba en 255, fora de rang.) exit sense argument retorna el codi de l'última ordre: sigues explícit. I evita inventar-te codis per sobre de 125, que xoquen amb els reservats; en tens de sobres amb el rang 3-125 per als teus propis significats, documentats a la capçalera. A 04-03 formalitzarem una taula per als nostres scripts.

La Marta demana el mateix cada matí: «està amunt la web, queda disc, i hi ha hagut errors aquesta nit?». L'escrivim tal qual, com una tirada d'ordres, aplicant la plantilla de l'apartat anterior.

Ja és infinitament millor que tres ordres a l'historial. Però és honestament dolent, i convé que vegis per què des del principi, perquè aquella llista és l'índex de la resta del mòdul:

• Les constants són dins de l'script i no accepta opcions: ni -h, ni un llindar diferent, ni mode silenciós (04-02 i 04-03).
• Imprimeix el llindar però no el compara amb res. No hi ha cap decisió: si el disc estigués al 95 % diria «95%» tan tranquil (04-04).
• Tres blocs gairebé idèntics que demanen a crits ser funcions (04-05), i si errors.log no existeix l'script mor a mitges amb un missatge lleig (04-06).
• Sempre retorna 0, així que cap monitoració no el pot fer servir (04-07).

Desa'l tal qual: al final del mòdul el compararàs amb la seva versió final.

Bash té una sintaxi plena de paranys i un intèrpret que gairebé mai no es queixa: escriu $fitxer sense cometes i funcionarà durant mesos, fins al dia que aparegui un nom amb un espai. L'anàlisi estàtica no és opcional en shell.

Tres avisos en quatre línies i tots tres són bombes de rellotgeria: sense cometes, un directori amb espais es parteix en dos arguments; i si el cd falla, el rm -f s'executa al directori on estiguessis. Cada codi SCxxxx té la seva pàgina al wiki de ShellCheck; a 04-06 esmicolarem els quatre més freqüents. La regla del mòdul des d'avui: cap script no es dona per acabat fins que shellcheck no diu res.

shfmt formata en lloc de criticar: -i 4 fixa quatre espais, -d ensenya què canviaria sense tocar res (el costum de --dry-run del curs) i -w escriu. Sobre estil, tres decisions que no discutirem més: quatre espais d'indentació (mai tabuladors, que es trenquen en copiar), línies de menys de 100 caràcters partint amb \, i una instrucció per línia.

• Escriure l'script a Windows i pujar-lo. Els finals CRLF fan que el shebang sigui #!/usr/bin/env bash\r i l'error, bad interpreter: No such file or directory, no diu res. Diagnostica'l amb file script.sh i arregla'l amb dos2unix.
• Deixar línies abans del shebang. Ha de ser la primera línia, començant a la columna 1. I no anomenis test.sh el teu script: test és un builtin i el conflicte de noms dona maldecaps.
• Executar amb sh script.sh un script amb shebang de Bash. El shebang s'ignora quan invoques l'intèrpret a mà: és la causa número u de «funciona al meu terminal i falla al servidor».
• Esperar que un script canviï el teu directori o les teves variables. No pot: és un altre procés. Si de debò ho necessites, és una funció o un fitxer per fer source. I no oblidis l'exit 0 final: si l'última línia és un grep sense coincidències, el teu script correcte retorna 1 i cron t'avisa d'una fallada inexistent.
• Consell: durant el desenvolupament, bash -n script.sh comprova la sintaxi sense executar res; costa un segon i evita descobrir un fi que falta a mig desplegament. Integra a més shellcheck al teu editor i comença cada script copiant la plantilla de l'apartat 7.

Exercici 1. Demostra empíricament, amb un sol fitxer i sense editar-lo entre proves, la diferència entre bash script.sh, ./script.sh i source script.sh. L'script ha de definir una variable, canviar de directori i imprimir el seu propi PID. Explica què observes en cada cas i per què.

Exercici 2. Escriu ~/scripts/info_release.sh: quina versió de Tramontana està activa (resolent /opt/tramontana/app), quant ocupa aquell release i quan es va desplegar. Aplica la plantilla completa, deixa'l net de shellcheck i publica'l a ~/bin com a info-release.

Exercici 3. En Luis ha deixat aquest script al servidor. Troba-hi quatre problemes diferents sense executar-lo, justifica'n cadascun i reescriu-lo.

Solució 1. $$ conté el PID del shell que executa el codi: és el testimoni que delata si hi ha hagut procés nou.

bash /tmp/demo_ambit.sh dona el mateix resultat que ./: PID diferent del del teu shell, per tant procés nou, i el cd i la variable moren amb ell. Només canvia el mecanisme: bash fitxer arrenca Bash explícitament i ignora el shebang, mentre que ./fitxer fa que el nucli llegeixi el shebang i decideixi —i per això aquell cas, i només aquell, exigeix el bit x—. El tercer imprimeix el mateix PID 3120: no hi ha procés nou, l'ha executat el teu propi Bash, i per això tot persisteix. El ${LA_MEVA_VARIABLE:-(no existeix)} evita que echo imprimeixi un buit ambigu; el veuràs en detall a 04-02.

Solució 2.

Solució 3. Els quatre problemes, de més greu a menys:

1. cd sense comprovar seguit de rm -rf *. El defecte letal: si el directori no existeix o no hi tens permís, el cd falla, l'script continua on estiguessis i esborra tot el que hi hagi allà. És SC2164, i s'arregla amb cd ... || exit o amb mode estricte.
2. #! /bin/sh amb [[ ]]. Dos errors: l'espai després de #! l'admet Linux però no tots els Unix, i sobretot /bin/sh és dash, que no coneix [[ ]]. L'script mor a l'última línia amb [[: not found.
3. if [[ $? == 0 ]]. Redundant i fràgil: en Bash es ramifica directament sobre l'ordre (if rm -rf ...; then), com veurem a 04-04. A més == compara cadenes on s'hauria de fer servir un test numèric.
4. Falta tota la resta: sense capçalera, sense mode estricte, sense exit explícit, i el comentari «neteja temporals» no diu què considera temporal ni des de quan. Un rm -rf * mereix més explicació que cap altra línia del fitxer.

La versió reescrita fa a més el que el nom promet —esborrar l'antic, no tot—:

Ja no hi ha cd, així que el perill desapareix d'arrel, i el mode estricte avorta si find falla.

Tens els fonaments, i són més dels que sembla.

• Saps quan escriure un script i quan n'hi ha prou amb un àlies, una funció o Ansible, amb la regla de les tres repeticions com a criteri.
• Entens que un script és text pla amb ordres, domines el shebang i per què #!/usr/bin/env bash és l'elecció per defecte, i coneixes el parany que a Ubuntu /bin/sh és dash i [[ ]] no hi existeix.
• Distingeixes les tres formes d'executar un script i per què només source afecta el teu shell; col·loques els scripts a ~/scripts, els publiques amb un enllaç a ~/bin i continues sense posar . al PATH.
• Arrenques tot script amb la mateixa plantilla —shebang, capçalera amb ús, set -euo pipefail, constants en majúscules, cos i exit 0—, comentes el perquè, retornes codis de sortida amb significat i passes shellcheck abans de donar res per acabat.

revisio_salut.sh ja existeix i ja funciona, però té les constants clavades al codi, no compara res i no sap dir si el resultat és bo o dolent. A la lliçó següent, Variables i Tipus de Dades, ataquem la primera mancança: veuràs que en Bash tot és una cadena i què implica això, dominaràs l'expansió de paràmetres —aquella col·lecció de ${VAR#...}, ${VAR:-...} i ${VAR//.../...} que converteix deu línies en una—, aprendràs per què Bash no sap sumar decimals i què fer amb l'import mitjà de reserves.csv, i comptaràs reserves per casa amb matrius associatives sense sortir del shell. En acabar-la, revisio_salut.sh tindrà la seva configuració fora del cos de l'script.