Spell checking

chezmoi.org

@@ -1,9 +1,9 @@
 * Chezmoi
 
-  E' uno strumento che negli ultimi tempi è argomento di molti articoli e/o video.
+  Uno strumento che negli ultimi tempi è argomento di molti articoli e/o video.
 
-  Si tratta di uno strumento scritto in GO e che quindi, oltre ad offrire il vantaggio di non avere
-  dipendenze esterne, è effettivamente multipiattaforma potendo funzionare sui canonici Linux/MacOS,
+  Si tratta di uno software scritto in GO e che quindi, oltre ad offrire il vantaggio di non avere
+  dipendenze esterne, è effettivamente multi-piattaforma potendo funzionare sui canonici Linux/MacOS,
   ma anche su Windows.
   
 * La filosofia
@@ -19,9 +19,9 @@
   Il comando può essere scomposto andando ad utilizzare soltanto la parte relativa al download e
   all'installazione del programma.
 
-  L'installazion può avvenire con diversi metodi. Il metodo che funziona sempre è quello di usare
+  L'installazione può avvenire con diversi metodi. Il metodo che funziona sempre è quello di usare
   lo script presente su Github. Qui sarà mostrato lo script per Linux basato su "sh", ma è possibile
-  usare anche lo script basato su "poeershell": vedere la documentazione.
+  usare anche lo script basato su "powershell" (vedere la documentazione).
   
 ** Prima installazione con repository da creare
    
@@ -76,7 +76,7 @@
 
   Per aggiungere un nuovo dotfile alla gestione si usa il comando ~chezmoi add <path/to/file>~
 
-  Assmendo di avere i dotfiles già presenti nella nostra home e volendoli aggiungere alla gestione
+  Assumendo di avere i dotfiles già presenti nella nostra home e volendoli aggiungere alla gestione
   possiamo fare:
 
 ** Emacs
@@ -109,7 +109,7 @@
 
    #+begin_example
      chezmoi cd # apre una shell posizionandosi nella directory del repository
-     git add . # aggingiamo il tutto allo sage
+     git add . # aggiungiamo il tutto allo stage
      git commit -m "Aggiunto Emacs"
      exit # esce dalla shell creata da chezmoi
    #+end_example
@@ -137,6 +137,6 @@
 
 ** Git
 
-   Nel repository di esempio si è usato il meccanimso dei template per configurare l'utente di Git
+   Nel repository di esempio si è usato il meccanismo dei template per configurare l'utente di Git
    (in .gitconfig) in base all'hostname.
    

dotbot.org

@@ -106,7 +106,7 @@
          ~/.vimrc: vim/.vimrc
    #+end_example
 
-   Nell'esmpio ho creato i collegamenti per VIM e Emacs. Ho preferito mantenere
+   Nell'esempio ho creato i collegamenti per VIM e Emacs. Ho preferito mantenere
    nel repository i nomi dei files e delle directory che iniziano con il
    punto, ma non è strettamente necessario.
 
@@ -118,7 +118,7 @@
 
 ** Il risultato finale
 
-   Il risultato finale del contenuto di ~install.conf.yaml~ dovrebbe quindi essre:
+   Il risultato finale del contenuto di ~install.conf.yaml~ dovrebbe quindi essere:
 
    #+begin_example
      - defaults:
@@ -166,7 +166,7 @@
 
  *CAVEAT*
 
-  Dotbot NON crea i link simbolici se il target già esiste come file o directroy normale.
+  Dotbot NON crea i link simbolici se il target già esiste come file o directory normale.
   Eventuali link simbolici esistenti sono sostituiti in presenza della direttiva ~relink: true~
   
 * Informazioni aggiuntive

gnu_stow.org

@@ -7,7 +7,7 @@
   La sua specializzazione è gestire i link simbolici e per
   questo è perfettamente adatto allo scopo di gestire i
   dotfiles in un repository git, files che poi saranno
-  aggancciati come link simbolici nelle directory standard.
+  agganciati come link simbolici nelle directory standard.
   
 * I "package"
 
@@ -62,7 +62,7 @@
  ~stow bash~ crea i limk simbolici del package "bash". Mantenendo le impostazioni
   predefinite e assumendo di aver eseguito il comando posizionati nella directory
   $HOME/.dotfiles Stow creerà un link simbolico di nome ".bash_alias" nella $HOME
-  che andrà a puntare a ~$HOME/.dotfiles/bash/.bas_alias~
+  che andrà a puntare a ~$HOME/.dotfiles/bash/.bash_alias~
 
   E' possibile indicare più package: ~stow bash htop~ creerà i link simbolici per
   i package "bash" e "htop".
@@ -92,7 +92,7 @@
 
 * Configurazioni separate per macchine separate
 
-  E' un funzionalità non gestità direttamente da Stow.
+  E' un funzionalità non gestita direttamente da Stow.
   Tuttavia, con un po' di manualità si possono creare package specifici sfruttando
   il fatto che Stow non funziona con dei "sotto-package" e utilizzando in modo
   corretto i parametri ~-d~ e ~-t~

homerepo.org

@@ -5,7 +5,7 @@
 
   La forma più comune con cui questo metodo viene messo in pratica consiste
   nella creazione di un repository Git di tipo "bare" nella ~$HOME~ e poi
-  utlizzarlo con le opzioni standard di Git.
+  utilizzarlo con le opzioni standard di Git.
 
   Git consente infatti di indicare, tramite appositi parametri, sia la
   directory con i files da tracciare, sia la directory con i suoi dati.
@@ -27,17 +27,17 @@
    Se si vuole creare un nuovo repository il comando da dare è:
  ~git init --bare .dotfiles~
 
-   Se invece si vuole clonare un repository remoto il comendo da dare è:
+   Se invece si vuole clonare un repository remoto il comando da dare è:
  ~git clone --bare <url>~ dove con ~<url>~ si indica l'indirizzo da
    cui clonare con l'accesso http/https o con l'accesso ssh.
 
 ** Definizione dell'alias
 
    Per rendere più semplice l'operatività si utilizza un alias.
-   Si può scegliere un qualisi nome per l'alias.
+   Si può scegliere un qualsiasi nome per l'alias.
 
    L'alias va reso disponibile ad ogni login, qui si aggiunge al
- ~.bashrc~. Per aggiungerlo si può modiificare il file con un editor
+ ~.bashrc~. Per aggiungerlo si può modificare il file con un editor
    o accodarlo con i comandi di shell.
 
    Per aggiungere l'alias accodandolo:
@@ -61,7 +61,7 @@
 
    Alcuni esempi
 
-*** Aggiuntere un nuovo file all'area di stage
+*** Aggiungere un nuovo file all'area di stage
 
  ~dotfiles add /path/to/file~
 
@@ -82,7 +82,7 @@
    questo funziona soltanto se il numero di macchine è limitato e si lavora con
    molta diligenza.
 
-   Non è semplice avere dei diff tra le versioni proprio perchè si usa un
+   Non è semplice avere dei diff tra le versioni proprio perché si usa un
    repository bare.
 
  ~dotfiles reset --hard~ potrebbe causare un infarto.

seratadotfiles.org

@@ -412,7 +412,7 @@
   possibile un unico file di configurazione che possa andare bene sia su Windows che su Linux e mettere
   questi files di configurazione in un repository Git in modo da poterlo facilmente scaricare da
   più macchine sfruttando tutti i vantaggi di un VCS. A corollario di questo un qualche sistema che
-  mi consenta un qualche automatismo nel bootstrap della configurazione.
+  mi consenta una forma di automatismo nel bootstrap della configurazione.
 
   Fino a quando non ho cominciato ad accarezzare l'idea di parlare dei dotfiles quello che avevo
   mi è sempre stato più che sufficiente. Cercando però documentazione per approfondire ho trovato che
@@ -422,6 +422,11 @@
   Nell'ambito dei dotfiles c'è una certa effervescenza sia negli articoli di blog che spiegano i vari
   approcci, sia negli strumenti di gestione che presentano con una certa frequenza nuovi elementi.
 
+  Infine, come spesso succede, non esiste un metodo unico che soddisfi tutti. Una volta presa coscienza
+  di cosa si vuole fare sarà necesario investire un po' di tempo sperimentando vari metodi e strumenti,
+  anche esotici, per poi scegliere quello che più troviamo adatto oppure, perché no, creare un ambiente
+  fatto su misura.
+
 * Footnotes
 
 [fn:1]https://it.wikipedia.org/wiki/Rob_Pike

yadm.org

@@ -83,7 +83,7 @@
   E' possibile posizionare uno script di nome ~bootstrap~ (deve chiamarsi così) in
  ~$HOME/.config/yadm~.
 
-  Questo file, che deve essere posizionato manualmente e deve essere eseguuibile,
+  Questo file, che deve essere posizionato manualmente e deve essere eseguibile,
   sarà richiamato ed eseguito con il comando
 
   #+begin_example
@@ -102,12 +102,12 @@
 
 * Encryption
 
-  Se vi fidate, consente la memorizzazione nel repository di informazioni crittate. L'esempio tipico
+  Se vi fidate, consente la memorizzazione nel repository di informazioni crittografate. L'esempio tipico
   è quello relativo alla gestione delle chiavi SSH.
 
 * Hooks
 
-  Per ogni comando di yadm è possible fornire degli script da eseguire prima e/o dopo l'esecuzione del
+  Per ogni comando di yadm è possibile fornire degli script da eseguire prima e/o dopo l'esecuzione del
   comando stesso.
 
   Gli hook sono gestiti con attenzione al risultato dell'esecuzione dello script. Se, ad esempio,