* Riscopriamo l'acqua calda: cosa sono i "dotfiles"?
Tutti lo sapete già: i dotfiles sono quei files (o directory) che iniziano con il carattere punto (".") e
che proprio per questa caratteristica risultano normalmente non visibili con gli strumenti che elencano
il contenuto del filesystem.
Sono prevalentemente dominio del mondo Unix-like dove vengono tradizionalmente utilizzati per memorizzare,
relativamente allo user space, i dati utili al funzionamento dei programmi, ma si possono tranquillamente
trovare anche in sistemi con Windows.
Rob Pike[fn:1] racconta che i dotfiles sono nati come effetto collaterale di una scorciatoia nel codice
di Unix presa, non si sa se da Ken (Thompson)[fn:2] o da Dennis (Ritchie)[fn:3] [!], fatta per non mostrare
le entries "." e ".." quando il filesystem di Unix divenne gerarchico[fn:4].
Da sempre i dotfiles, nell'accezione di files di configurazione, sono posizionati nella ~$HOME~ e questo
porta, con l'avanzare del tempo dalla prima installazione, ad un certo affollamento fisiologicamente
dovuto ai nuovi programmi che vengono di volta in volta installati e che hanno bisogno di memorizzare
i propri dati.
Questa condizione di affollamento ha iniziato a migliorare con la progressiva adozione dello standard
"XDG Base Directory Specification"; standard che si prefigge lo scopo di mettere ordine nel marasma
dei files creati dai vari programmi nella home directory.
* Note sullo standard "XDG Base Directory Specification"
Si tratta di un insieme di specifiche, redatte dal X Desktop Group, che puntano standardizzare il
posizionamento dei dotfiles, definendone delle categorie e indicando le directory all'interno della
home destinate ad essere usate per ciascuna categoria.
Molte delle applicazioni preesistenti sono state adeguate o sono in fase di adeguamento.
Ciascuna applicazione segue però le proprie scelte per la compatibilità con la gestione legacy delle
impostazioni. Mentre alcune danno precedenza alla ricerca nelle directory indicate dalle specifiche e solo
se la ricerca non ha esito proseguono con il metodo legacy, altre agiscono in modo diametralmente opposto.
Allo stesso modo la posizione dove i files vengono creati automaticamente varia da un'applicazione
all'altra. Occorre quindi consultare la documentazione dell'applicazione per i dettagli.
Da notare infine che il files e le directory poste all'interno della struttura definita dalle specifiche
normalmente non sono nascosti.
Il wiki di Arch contiene un elenco di applicazioni che supportano le specifiche con indicazioni
relative anche ai percorsi legacy.
Un paio di link esplicativi:
- [[https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html][XDG Base Directory Specification (X Desktop Group)]][fn:5]
- [[https://wiki.archlinux.org/title/XDG_Base_Directory][XDG Base Directory (Arch Wiki)]][fn:6]
Le categorie e le directory associate sono tipicamente indicate con delle variabili d'ambiente che,
se non impostate, prevedono dei percorsi predefiniti.
** ~$XDG_CONFIG_HOME~
Destinata a contenere i files e le directory di configurazione specifici dell'utente.
E' analoga a ~/etc/~.
Se la variabile non è impostata assume solitamente il valore predefinito di ~$HOME/.config~.
** ~$XDG_CACHE_HOME~
Destinata a contenere dati non essenziali (cache) dell'utente.
E' analoga a ~/var/cache~.
Se la variabile non è impostata assume solitamente il valore predefinito di ~$HOME/.cache~.
** ~$XDG_DATA_HOME~
Destinata a contenere i files di dati dell'utente.
E' analoga a ~/usr/share~.
Se la variabile non è impostata assume solitamente il valore predefinito di ~$HOME/.local/share~.
** ~$XDG_STATE_HOME~
Destinata a contenere i files di stato delle applicazioni.
E' analoga a ~/var/lib~.
Se la variabile non è impostata assume solitamente il valore predefinito di ~$HOME/.local/state~.
Con i files di stato si intendono files che contengono informazioni di cui è necessaria la
persistenza tra i riavvii delle applicazioni ma che comunque non sono fondamentali.
Un esempio tipico è rappresentato da logs, history, recents ecc.
** Altre variabili
Lo standard prevede anche altre variabili d'ambiente che consentono di specificare elenchi ordinati
di percorsi di ricerca quando i files non sono presenti nelle directory ~$XDG_???_HOME~. Si veda la
documentazione dello standard.
** Estensioni alla specifica
Molte distribuzioni Linux prevedono delle estensioni alla specifica che stanno diventando standard
de-facto. Una estensione molto comune è l'uso della directory ~$HOME/.local/bin~ che normalmente
non esiste ma che è sempre più spesso inclusa nel $PATH come impostazione predefinita.
* E' importante gestire i dotfiles
I dotfiles contengono dati importanti, per questo è bene gestirli in modo adeguato.
Si potrebbe pensare che con le normali operazioni di backup si risolva definitivamente il problema.
Soluzione semplice, senza troppi sbattimenti ed efficace.
In realtà i backup sono il minimo sindacale sotto il quale non si deve mai scendere, e la cosa deve
riguardare tutto il sistema e non i soli dotfiles. Repetita iuvant.
Ma i dotfiles sono spesso più complessi di semplici elenchi di parametri composti da chiave/valore.
Capita non di rado che contengano script di shell o scritti in altri linguaggi.
C'è di più: a differenza di Windows sono praticamente sempre files di testo (ma quella è un'altra storia)
e quando si parla di files di testo la prima cosa che viene in mente a un programmatore è VCS, alias Git!
* Perché usare Git per i dotfiles?
Perché no? L'uso Git e un minimo di organizzazione porta in dote tutti quei vantaggi tipici dei VCS:
- E' possibile vedere tutte le modifiche che sono state fatte nel tempo e, compatibilmente con la qualità
della descrizione inserita nel commit, risalire alla motivazione della modifica.
- E' possibile ripristinare velocemente modifiche fatte per errore; molto più semplice e veloce che
ripristinare un backup.
- E' relativamente semplice e veloce gestire le configurazioni di più macchine in un unico repository.
- Usando un repository in hosting è facile accedere ai propri files di configurazione in ogni parte
del mondo.
- Per lo stesso motivo di cui sopra è possibile e semplice condividere le proprie impostazioni con altri.
Mettere i dotfiles in un repository è indubbiamente utile. Occorre però ricordarsi di prestare attenzione
a cosa ci si mette: _evitare assolutamente di mettere nel repository file che contengano informazioni sensibili_.
Qualcuno ha detto ~$HOME/.ssh~? In realtà vedremo che certi strumenti consento la memorizzazione crittografata
di questi files.
* Stessi dotfiles su macchine diverse
Si diceva che è relativamente facile gestire le configurazioni su macchine diverse. Con un po' di impegno in
più si può anche avere un certo automatismo anche su piattaforme diverse.
Questa funzionalità è raggiungibile sia tramite l'uso di script personalizzati che tramite l'uso di strumenti
che prevedono l'uso multi-piattaforma.
Occorre però tenere presente che, mentre per il mondo Linux/Mac il numero di strumenti utilizzabili è elevato,
lo stesso con accade per il mondo Windows dove il numero di strumenti decisamente ridotto.
* Ok, da dove comincio?
Occorre usare un "qualcosa", software o metodo, che aiuti in questa gestione.
Parlando di dotfiles mantenuti in repository Git, le argomentazioni sul metodo che si trovano in rete portano
essenzialmente a due scuole di pensiero:
- Uso di un bare repository. all'interno della home. :: E' solitamente posizionato nella home, ma contrariamente
a quanto si possa pensare in prima battuta, non si tratta far diventare la home un repository.
Si tratta appunto di creare un bare repository che sarà contenuto in una subdirectory della home, subdirectory
che può essere nascosta e spesso è chiamata ~.dotfiles~.
Le operazioni di interazione con il repository saranno definite con degli alias di shell.
Questo approccio è veramente semplice ed efficace, ma soffre di qualche idiosincrasia.
Mentre è immediatamente fattibile con Linux e similari, con Windows ci si può arrivare soltanto con l'uso della
git-bash, di WSL o di powershell (questa sconosciuta).
Questo metodo diventa infine sempre più complicato se si vogliono avere configurazioni leggermente diverse
da macchina a macchina e mantenere un repository unico.
Alcuni link sull'argomento:
- [[https://www.atlassian.com/git/tutorials/dotfiles][The best way to store your dotfiles: A bare Git repository (Atlassian)]][fn:7]
- [[https://www.ackama.com/blog/posts/the-best-way-to-store-your-dotfiles-a-bare-git-repository-explained][The best way to store your dotfiles: A bare Git repository \ast{}\ast{}EXPLAINED\ast{}\ast{}]][fn:8]
- [[https://daniele.tech/2021/03/how-to-manage-dotfiles-with-a-git-bare-repository][How to manage dotfiles with a Git bare repository]][fn:9]
- Uso di un repository normale. :: Si tratta di un normale repository Git con la sua working directory e
contenuto all'interno della home o in una qualsiasi altra directory. Anche qui non si tratta di far diventare
la home un repository.
Si differenzia dall'altro approccio perché mentre nel primo i files sono effettivamente presenti nella
home, in questo si andrà tipicamente ad utilizzare dei link simbolici. Con questo metodo si sfruttano
le capacità del filesystem per operare direttamente sul file nel repository come se fosse nella home.
La gestione del repository avviene normalmente e con l'uso di script personalizzati o strumenti appositi
è possibile gestire facilmente i link simbolici ma anche eventuali differenze tra vari PC.
La differenza tra le due scuole di pensiero si evidenzia anche nel come si devono gestire le modifiche.
Con il metodo del bare repository tutto si limita ad usare degli alias che prevedano i parametri necessari
ma continuando a ragionare come se si avesse a che fare con un normale repository.
Con il repository normale, invece, occorre avere un qualcosa che ne consenta la gestione.
Da questo punto di vista, scartando l'opzione di fare tutto a mano di volta in volta, si può
affrontare la cosa in vari modi.
** Mi faccio la gestione in casa
Con le giuste competenze e dedicandoci tempo si possono creare delle procedure che consentano la gestione
dei dotfiles accontentando le nostre più particolari esigenze. E' la strada scelta da molti e, quasi
certamente, è alla base dei tool che nel tempo sono stati presentati in rete. E' probabilmente l'unica
strada per raggiungere il massimo grado di soddisfazione, ma è anche quella più impegnativa.
Questo approccio consente anche la gestione di elementi non necessariamente attinenti ai dotfiles.
Facendo tutto su misura si può naturalmente andare a gestire anche impostazioni di sistema e non