1.16 Step | WriteControlScript + PatchBashrc

Gli ultimi due step: installano il comando helper odoo e chiudono la terza protezione critica del progetto (C3) — la cura sui file personali dell'utente. Vivono in src/steps/write_control_script.rs e src/steps/patch_bashrc.rs. Port di lib/control_script.sh.

Completano la triade delle protezioni: anti-drop DB (non distruggere) · hard-stop init (non scrivere) · bashrc chirurgico (non alterare).

---

Ownership: SUDO_USER, non odoo né root

Questi artefatti appartengono a chi ha lanciato sudo (SUDO_USER), non all'utente odoo e non a root. Il comando è installato solo per quell'utente (~/.local/bin), mai globalmente in /usr/local/bin — scelta di sicurezza del Bash originale (ridurre l'esposizione), preservata. La home si determina via getent passwd <user>, non si assume /home/<user>. SUDO_USER assente → errore.

---

14a — WriteControlScript (pulito)

Roba nostra, in dir dell'utente. Segue il pattern degli step precedenti.

Fase	Comportamento
snapshot	script ~/.scripts/odoo.sh e symlink ~/.local/bin/odoo esistono già? + le dir esistevano?
run	scrive sempre odoo.sh (wrapper systemctl {start|stop|restart|status} + dev), chmod +x, symlink se manca, chown a SUDO_USER. Se lo script c'era già, prima ne fa un backup
undo	CreatedByUs → rimuove; Preexisting → rimette il backup al suo posto. Le dir solo se create da noi e vuote

Test: ownership == SUDO_USER (mai odoo/root), nessun path in /usr/, script preesistente salvato e ripristinato.

Perché lo script si riscrive sempre. Il suo contenuto lo generiamo noi e porta dentro il nome del servizio (SERVICE_NAME=odoo18). Saltarlo perché «esiste già» significava che, reinstallando una versione diversa di Odoo, l'helper odoo continuava a pilotare il servizio vecchio — e l'utente lo scopriva solo quando odoo restart non faceva quello che doveva.

Il PreState qui non protegge un contenuto altrui: protegge la decisione di rimuoverlo all'undo. Ma un file con quel nome potrebbe comunque essere di qualcun altro, e non abbiamo modo di saperlo: perciò lo si mette da parte prima di riscriverlo, e l'undo lo rimette — lo stesso trattamento del vhost nginx e dell'odoo.conf.

---

14b — PatchBashrc (la mutazione più delicata dell'installer)

Il .bashrc è il file di config più intimo dell'utente: alias, funzioni, roba sua. La promessa "chirurgico" qui significa che, se l'utente fa rollback, il suo file torna byte per byte com'era — senza la nostra riga, senza cicatrici.

Aggiungiamo esattamente una riga, solo se non c'è già:

export PATH="$HOME/.local/bin:$PATH"

Fase	Comportamento
snapshot	il .bashrc esiste? la riga è già presente? (match di riga esatto, grep -Fqx)
run	se assente: backup del file, poi append della SINGOLA riga (mai riscrivere il file intero)
undo	se aggiunta da noi: ripristino da backup (primario) → fallback rimozione della riga esatta

Regole ferme (CLAUDE.md)

• Mai riscrivere/troncare il .bashrc intero. Solo append/rimozione della singola riga, o ripristino del backup.
• Match esatto, non fuzzy: se l'utente aveva una riga PATH diversa scritta a mano, l'undo non la tocca.
• Riga già presente (Preexisting) → non è nostra → run/undo no-op (niente duplicati, niente rimozioni).
• Se il file non esisteva e l'abbiamo creato noi → l'undo lo rimuove.

Perché il ripristino-da-backup è il metodo primario

Riporta il file allo stato esatto pre-modifica, senza alcun rischio di rimuovere la riga sbagliata. Il match-esatto (remove_exact_line) è il fallback robusto quando il backup non è disponibile.

---

Note di design

• Nessun canale step→step aggiunto: sudo_user è input read-only nel Context (da env, come os_info), non uno stato condiviso mutabile. Lo stato condiviso resta il solo db_created_by_us.
• control_script_content e remove_exact_line sono funzioni pure, testate a parte.
• Test protettivi di C3: round-trip del .bashrc (dopo run+undo, identico all'originale con alias e funzioni intatti), riga già presente → no-op, .bashrc creato→rimosso, e una riga PATH diversa dell'utente resta (match esatto).