În Bash nu există tranzacții native ca într-o bază de date. Totuși, poți construi scripturi „tranzacționale” dacă tratezi fiecare schimbare ca pe o operațiune cu precondiții, efect controlat și posibilitate de compensare. Ideea de bază este simplă: înainte să modifici ceva important, verifici starea inițială, notezi ce ai schimbat și pregătești pașii de rollback pentru situația în care execuția se oprește la jumătate. Pentru administratori, freelanceri tehnici și firme mici, abordarea aceasta reduce riscul de configurări incomplete, downtime provocat de scripturi grăbite și intervenții manuale făcute sub presiune.
Primul principiu este să nu tratezi set -euo pipefail ca pe o garanție absolută. În Bash, set -e ajută, pentru că oprește scriptul la multe erori, iar nounset și pipefail fac comportamentul mai strict. Dar documentația Bash și avertismentele ShellCheck arată clar că există contexte în care set -e nu se comportă intuitiv, de exemplu în anumite funcții apelate din if sau în unele substituții de comandă. Asta înseamnă că pentru pașii critici merită să verifici explicit codul de ieșire și să nu presupui că shell-ul va opri totul exact unde te aștepți.
Al doilea principiu este rollback-ul explicit. În loc să scrii un script liniar de tipul „copiez, șterg, mut, repornesc”, definește de la început ce înseamnă revenirea. Dacă ai înlocuit un fișier de configurare, rollback-ul poate însemna restaurarea backupului. Dacă ai creat un director temporar, rollback-ul înseamnă ștergerea lui. Dacă ai pornit un serviciu doar după o modificare, rollback-ul poate însemna revenirea la versiunea anterioară și verificarea că serviciul pornește corect. În practică, ajută să aduni acțiunile de compensare într-o funcție dedicată și să o legi de trap, astfel încât să fie apelată automat la ERR sau EXIT, în funcție de design.
trap este una dintre cele mai utile unelte pentru astfel de scripturi. Bash permite asocierea unei acțiuni cu evenimente precum EXIT, ERR sau RETURN. Pentru un rollback sigur, modelul sănătos este să ai un „registru” intern al pașilor finalizați: de exemplu, marchezi că backupul a fost creat, că noul fișier a fost copiat într-o zonă temporară și că validarea a trecut. Funcția de rollback nu trebuie să presupună că toate etapele au rulat, ci să verifice ce s-a făcut deja și să inverseze doar acele părți. Aici intervine idempotenta: aceeași rutină de curățare ar trebui să poată rula de două ori fără să strice starea sistemului.
Al treilea principiu este separarea dintre pregătire și aplicare. Validează tot ce poți înainte de pasul cu impact: existența comenzilor necesare, permisiunile, spațiul liber, sintaxa fișierului de configurare, accesul la directoare și faptul că backupul poate fi scris. Folosește directoare și fișiere temporare create sigur, de exemplu cu mktemp, nu nume „ghicite” în /tmp. Abia după ce etapa de pregătire trece, faci schimbarea finală. În multe scenarii, asta înseamnă să generezi noua configurație într-un fișier temporar, să o validezi și apoi să o pui în locul fișierului activ.
Logarea este al patrulea strat de protecție. Un script tranzacțional fără loguri bune devine greu de investigat exact când ai nevoie de el. Loghează începutul execuției, verificările trecute, fiecare modificare aplicată, fiecare backup creat și motivul rollback-ului. Separă mesajele informative de erori și include suficiente detalii pentru audit, dar fără secrete. Pentru taskuri recurente, este util să ai și un cod de stare final: succes, eșec cu rollback reușit sau eșec cu intervenție manuală necesară.
În final, tratează scriptul ca pe un mecanism de reducere a riscului, nu ca pe o improvizație rapidă. Rulează-l întâi într-un mediu de test, verifică scenariile de eșec parțial și folosește ShellCheck pentru erorile comune de quoting, semnale și control al fluxului. Un script Bash tranzacțional bun nu încearcă să fie „deștept”, ci previzibil: validează înainte, modifică minim, loghează clar și știe să revină curat când ceva nu merge până la capăt.
