Primo commit
This commit is contained in:
me
commit
42c8d92f54
|
|
@ -0,0 +1,59 @@
|
|||
|
||||
# Created by https://www.toptal.com/developers/gitignore/api/emacs
|
||||
# Edit at https://www.toptal.com/developers/gitignore?templates=emacs
|
||||
|
||||
### Emacs ###
|
||||
# -*- mode: gitignore; -*-
|
||||
*~
|
||||
\#*\#
|
||||
/.emacs.desktop
|
||||
/.emacs.desktop.lock
|
||||
*.elc
|
||||
auto-save-list
|
||||
tramp
|
||||
.\#*
|
||||
|
||||
# Org-mode
|
||||
.org-id-locations
|
||||
*_archive
|
||||
|
||||
# flymake-mode
|
||||
*_flymake.*
|
||||
|
||||
# eshell files
|
||||
/eshell/history
|
||||
/eshell/lastdir
|
||||
|
||||
# elpa packages
|
||||
/elpa/
|
||||
|
||||
# reftex files
|
||||
*.rel
|
||||
|
||||
# AUCTeX auto folder
|
||||
/auto/
|
||||
|
||||
# cask packages
|
||||
.cask/
|
||||
dist/
|
||||
|
||||
# Flycheck
|
||||
flycheck_*.el
|
||||
|
||||
# server auth directory
|
||||
/server/
|
||||
|
||||
# projectiles files
|
||||
.projectile
|
||||
|
||||
# directory configuration
|
||||
.dir-locals.el
|
||||
|
||||
# network security
|
||||
/network-security.data
|
||||
|
||||
|
||||
# End of https://www.toptal.com/developers/gitignore/api/emacs
|
||||
|
||||
# Temporanei dell'export in pdf dei files di org
|
||||
*.tex
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
* Appunti per la "Serata Dotfiles"
|
||||
|
||||
La serata è dedicata alla gestione dei /dotfiles/.
|
||||
|
||||
Nel repository sono presenti files e directory utili per la serata.
|
||||
- [[seratadotfiles.org][File con gli appunti sull'argomento]] ([[seratadotfiles.pdf][anche in versione pdf]])
|
||||
- [[homerepo.org][File con gli appunti sul ~bare repository~ nella home]]
|
||||
- [[gnu_stow.org][File con gli appunti su ~GNU Stow~]]
|
||||
- [[dotbot.org][File con gli appunti su ~dotbot~]]
|
||||
- [[chezmoi.org][File con gli appunti su ~chezmoi~]]
|
||||
- [[yadm.org][File con gli appunti su ~yadm~]]
|
||||
- [[base][Directory con elementi di base per le demo]]
|
||||
|
||||
Ci sono poi altri repository utilizzati per le varie demo
|
||||
|
||||
|
|
@ -0,0 +1,15 @@
|
|||
# -*- mode: gitignore; -*-
|
||||
auto-save-list/
|
||||
elpa/
|
||||
emms/
|
||||
eshell/
|
||||
games/
|
||||
server/
|
||||
transient/
|
||||
url/
|
||||
|
||||
amx-items
|
||||
gb-init.el
|
||||
package-quickstart.el
|
||||
recentf
|
||||
projectile-bookmarks.eld
|
||||
|
|
@ -0,0 +1,163 @@
|
|||
;;; early-init.el --- File di configurazione "early-init" di GNU Emacs -*- mode: emacs-lisp; lexical-binding: t;-*-
|
||||
|
||||
;; Copyright (C) 2020 Geraldo Biotti
|
||||
|
||||
;; Author: Geraldo Biotti <gbiotti@gmail.com>
|
||||
;; Created: 20200731
|
||||
;; Keywords: init, early-init, .emacs.d, startup
|
||||
;; Compatiblity: emacs-version >= 27
|
||||
|
||||
;; This file is not part of GNU Emacs.
|
||||
|
||||
;; This program is free software: you can redistribute it and/or modify
|
||||
;; it under the terms of the GNU General Public License as published by
|
||||
;; the Free Software Foundation, either version 3 of the License, or (at
|
||||
;; your option) any later version.
|
||||
|
||||
;; This program is distributed in the hope that it will be useful, but
|
||||
;; WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
||||
;; General Public License for more details.
|
||||
|
||||
;; You should have received a copy of the GNU General Public License
|
||||
;; along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>.
|
||||
|
||||
;;; Commentary:
|
||||
|
||||
;; Questo file contiene le impostazioni di GNU Emacs che vengono eseguite
|
||||
;; durante la fase di Early Init.
|
||||
;;
|
||||
;; La fase di Early Init e' stata introdotta con GNU Emacs versione 27
|
||||
;;
|
||||
;; Per maggiori informazioni fare riferimento al manuale di GNU Emacs
|
||||
;; versione 27 o successiva: 49.4.6 - The Early Init File
|
||||
|
||||
;;; To do:
|
||||
|
||||
;;; Change log:
|
||||
|
||||
;;; Code:
|
||||
|
||||
;; N.B.: Ho rimosso l'impostazione del lexical-binding:
|
||||
;; -*- lexical-binding: t; -*-
|
||||
|
||||
|
||||
;; Imposto l'ora di avvio di Emacs
|
||||
;; Servira' alla fine per determinare quanto tempo e' trascorso
|
||||
(defconst gb/emacs/emacs-startup-time (current-time))
|
||||
|
||||
;; Imposto le varibili di appoggio usate per ripristinare
|
||||
;; le impostazioni di default procedura di inizializzazione
|
||||
(defvar gb/emacs/gc-cons-threshold-original gc-cons-threshold
|
||||
"Valore originale di 'gc-cons-threshold' prima della modifica.
|
||||
Salvato per ripristinarlo alla fine della procedura di inizializzazione")
|
||||
|
||||
(defvar gb/emacs/gc-cons-percentage-original gc-cons-percentage
|
||||
"Valore originale di 'gc-cons-percentage' prima della modifica.
|
||||
Salvato per ripristinarlo alla fine della procedura di inizializzazione")
|
||||
|
||||
(defvar gb/emacs/file-name-handler-alist-original file-name-handler-alist
|
||||
"Valore originale di 'file-name-handler-alist' prima della modifica.
|
||||
Salvato per ripristinarlo alla fine della procedura di inizializzazione")
|
||||
|
||||
;; Imposta la soglia del garbage collector
|
||||
;; Da reimpostare poi ai valori corretti con apposito
|
||||
;; codice richiamato in after-init-hook
|
||||
(setq gc-cons-threshold (* 1024 (* 1024 1024)) ; 1 GByte
|
||||
gc-cons-percentage 0.6)
|
||||
|
||||
;; Imposta file-name-handler-alist
|
||||
;; Da reimpostare poi ai valori corretti con apposito
|
||||
;; codice richiamato in after-init-hook
|
||||
(setq file-name-handler-alist nil)
|
||||
|
||||
;; Aggiungo ad after-init-hook il codice necessario
|
||||
;; per reimpostare i valori di default nelle variabili
|
||||
;; usate qui sopra e fare una garbage-collect finale.
|
||||
;; Si usa una depth 90 (vedi docstring di di "add-hook")
|
||||
(add-hook 'after-init-hook
|
||||
'(lambda ()
|
||||
;; Non imposto piu' 'gc-cons-threshold' al suo valore originale ma, come
|
||||
;; riportato in molti siti ad un valore molto piu' alto.
|
||||
;; Si veda, ad esempio qui: https://emacs-lsp.github.io/lsp-mode/page/performance/
|
||||
;; (consultato 31/08/2020)
|
||||
;; (setq gc-cons-threshold gb/emacs/gc-cons-threshold-original)
|
||||
;; 100 Mb = (* 1024 (* 1024 100)))
|
||||
(setq gc-cons-threshold (* 1024 (* 1024 100)))
|
||||
;; Sempre https://emacs-lsp.github.io/lsp-mode/page/performance/
|
||||
;; raccomanda di impostare 'read-process-output-max' ad un valore di 1Mb
|
||||
;; (numero massimo di bytes letti in un singolo chunk dai subprocess)
|
||||
(setq read-process-output-max (* 1024 1024))
|
||||
(setq gc-cons-percentage gb/emacs/gc-cons-percentage-original)
|
||||
(setq file-name-handler-alist gb/emacs/file-name-handler-alist-original)
|
||||
(garbage-collect)
|
||||
(defvar gb/emacs/elapsed (float-time
|
||||
(time-subtract (current-time) gb/emacs/emacs-startup-time))
|
||||
)
|
||||
(message (emacs-init-time))
|
||||
(message "Loading done in %.3fs seconds and %d garbage collections [after-init]"
|
||||
gb/emacs/elapsed
|
||||
gcs-done)
|
||||
)
|
||||
90
|
||||
)
|
||||
|
||||
;; Non rende disponibili i package all'avvio di Emacs
|
||||
;; da usare qui e non in init.el
|
||||
(setq package-enable-at-startup nil)
|
||||
|
||||
;; Per GNU Emacs versione 27 e successive
|
||||
(when (not (version< emacs-version "27"))
|
||||
(progn
|
||||
;; Consente il caricamento dalla cache dei package
|
||||
(setq package-quickstart t)
|
||||
)
|
||||
)
|
||||
|
||||
;; Non ridimnensiona il frame in questo momento
|
||||
(setq frame-inhibit-implied-resize t)
|
||||
|
||||
;; Su Windows, assumendo di aver installato Scoop, ne metto il path
|
||||
;; in testa, altrimenti vengono prima trovati gli eseguibili nelle
|
||||
;; directory di sistema. Questo crea confusione, ad esempio concat
|
||||
;; "find" che esiste sia in ambiente Linux che in Windows, ovviamente
|
||||
;; con sintassi completamente diverse. Generalmente mi apsetto che
|
||||
;; le funzionalita' siano quelle del mondo Linux e non quelle del
|
||||
;; mondo Windows per cui faccio in modo che vengano lette per prima.
|
||||
;; Da notare che Scoop aggiunge le sue directory al Path, ma queste
|
||||
;; sono di tipo utente e vengono aggiunte al path dopo quelle di
|
||||
;; sistema. Si avra' un "doppione" nel path, ma va bene.
|
||||
(when (eq system-type 'windows-nt)
|
||||
(defvar gb/emacs/scoop-shim-path
|
||||
(concat (expand-file-name "~/scoop/shims")
|
||||
path-separator)
|
||||
"Percorso per 'scoop/shims' da aggiungere in testa al PATH."
|
||||
)
|
||||
;;(add-to-list 'exec-path "c:/Users/Geraldo/scoop/shims")
|
||||
(add-to-list 'exec-path gb/emacs/scoop-shim-path)
|
||||
;; (setenv "PATH" (concat gb/emacs/scoop-shim-path
|
||||
;; (getenv "PATH")))
|
||||
)
|
||||
|
||||
(provide 'early-init)
|
||||
|
||||
;;(progn
|
||||
;; (setq gb/frame-font
|
||||
;; (cond ((find-font (font-spec :name "DejaVu Sans mono")) '(font . "DejaVu Sans Mono-10"))
|
||||
;; ((find-font (font-spec :name "Consolas")) '(font . "Consolas-10"))
|
||||
;; ((find-font (font-spec :name "Inconsolata")) '(font . "Inconsolata-10"))
|
||||
;; ((find-font (font-spec :name "Courier New")) '(font . "Courier New-10"))
|
||||
;; ))
|
||||
;; (print gb/frame-font)
|
||||
;; (add-to-list 'default-frame-alist gb/frame-font)
|
||||
;; (add-to-list 'initial-frame-alist gb/frame-font))
|
||||
|
||||
;; ===========================================================================
|
||||
;; Local Variables:
|
||||
;; coding: utf-8-unix
|
||||
;; indent-tabs-mode: nil
|
||||
;; tab-width: 4
|
||||
;; End:
|
||||
;; ===========================================================================
|
||||
|
||||
;;; early-init.el ends here
|
||||
File diff suppressed because it is too large
Load Diff
Binary file not shown.
|
After Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 15 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 23 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 74 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 32 KiB |
File diff suppressed because one or more lines are too long
|
After Width: | Height: | Size: 23 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 330 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 335 KiB |
|
|
@ -0,0 +1,227 @@
|
|||
;;; init.el --- File di configurazione di GNU Emacs -*- mode: emacs-lisp; lexical-binding: t;-*-
|
||||
|
||||
;; Copyright (C) 2020 Geraldo Biotti
|
||||
|
||||
;; Author: Geraldo Biotti <gbiotti@gmail.com>
|
||||
;; Created: 20200731
|
||||
;; Keywords: init, early-init, .emacs.d, startup
|
||||
;; Compatiblity: emacs-version >= 27
|
||||
|
||||
;; This file is not part of GNU Emacs.
|
||||
|
||||
;; This program is free software: you can redistribute it and/or modify
|
||||
;; it under the terms of the GNU General Public License as published by
|
||||
;; the Free Software Foundation, either version 3 of the License, or (at
|
||||
;; your option) any later version.
|
||||
|
||||
;; This program is distributed in the hope that it will be useful, but
|
||||
;; WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
;; MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
||||
;; General Public License for more details.
|
||||
|
||||
;; You should have received a copy of the GNU General Public License
|
||||
;; along with GNU Emacs. If not, see <https://www.gnu.org/licenses/>.
|
||||
|
||||
;;; Commentary:
|
||||
|
||||
;; Questo file contiene le impostazioni di GNU Emacs che vengono eseguite
|
||||
;; durante la fase di Init.
|
||||
;; La fase di Init viene eseguita successivamente a quella di Early Init
|
||||
;;
|
||||
;; Per maggiori informazioni fare riferimento al manuale di GNU Emacs:
|
||||
;; 49.4 The Emacs Initialization File
|
||||
|
||||
;;; To do:
|
||||
|
||||
;;; Change log:
|
||||
|
||||
;;; Code:
|
||||
|
||||
;; ----------------------------------------------------------------------------------------
|
||||
;; https://etienne.depar.is/emacs.d/init.html
|
||||
;; https://github.com/MatthewZMD/.emacs.d
|
||||
|
||||
;; https://www.reddit.com/r/emacs/comments/2edbau/what_are_some_great_emacsd_examples/
|
||||
;; https://www.reddit.com/r/emacs/comments/2edbau/what_are_some_great_emacsd_examples/
|
||||
|
||||
;; https://github.com/AndreaCrotti
|
||||
|
||||
;; https://github.com/grettke/
|
||||
|
||||
;; Pastebin off topic:
|
||||
;; https://www.privacytools.io/
|
||||
;; https://alternativeto.net/list/18434/xenmaster-s-privacy-tools
|
||||
|
||||
;; https://send-anywhere.com/
|
||||
;; https://framasoft.org/en/
|
||||
;; https://gofile.io/welcome
|
||||
;; ----------------------------------------------------------------------------------------
|
||||
|
||||
;; N.B.: Ho rimosso l'impostazione del lexical-binding:
|
||||
;; -*- lexical-binding: t; -*-
|
||||
|
||||
;; Se la versione e' inferiore alla 26.1 emetto un warning
|
||||
(when (version< emacs-version "26.1")
|
||||
(warn "E' necessario che GNU Emacs sia in versione 26.1 o successiva!"))
|
||||
|
||||
(defun gb/emacs/package-setup ()
|
||||
"Function che imposta 'package'"
|
||||
;; Carico il modulo di gestione dei packages
|
||||
(require 'package)
|
||||
;; Carica sempre il file piu' recente tra '.el' e '.elc'
|
||||
(setq load-prefer-newer t)
|
||||
;; Aggiungo all'elenco dei repositories da cui scaricare i packages
|
||||
;; la versione "unstable" di Melpa
|
||||
(add-to-list 'package-archives
|
||||
'("melpa" . "https://melpa.org/packages/"))
|
||||
;; Genera dei warnings con i package-install
|
||||
(unless (bound-and-true-p package--initialized)
|
||||
(package-initialize))
|
||||
)
|
||||
|
||||
(defun gb/emacs/init-old-emacs-version ()
|
||||
"Function eseguita per il setup di init.el quando si sta usando Emacs
|
||||
in versione precedente alla 27"
|
||||
;; Early-init e' gestito automaticamente dalla versione 27 in poi
|
||||
;; Se esiste early-init.el lo carico
|
||||
(let ((gb/emacs/early-init-file (expand-file-name "early-init.el" user-emacs-directory)))
|
||||
(when (file-exists-p gb/emacs/early-init-file)
|
||||
(require 'early-init gb/emacs/early-init-file)))
|
||||
(gb/emacs/package-setup)
|
||||
)
|
||||
|
||||
(defun gb/emacs/init-new-emacs-version ()
|
||||
"Function eseguita per il setup di init.el quando si sta usando Emacs
|
||||
in versione 27+"
|
||||
;; Avvio package
|
||||
(gb/emacs/package-setup)
|
||||
)
|
||||
|
||||
;; Eseguo le impostazioni in base alla versione di GNU Emacs
|
||||
(if (version< emacs-version "27")
|
||||
(gb/emacs/init-old-emacs-version)
|
||||
(gb/emacs/init-new-emacs-version))
|
||||
|
||||
;; Delight e' un package che viene usato da use-package
|
||||
;; mi accerto che sia installato, se non lo e' lo installo
|
||||
;; N.B.: Se non si vuole averlo come dipendenza e' bene
|
||||
;; installarlo prima di use-package
|
||||
(unless (package-installed-p 'delight)
|
||||
(unless package-archive-contents
|
||||
(package-refresh-contents))
|
||||
(package-install 'delight))
|
||||
|
||||
;; Diminish e' un package che viene usato da use-package
|
||||
;; mi accerto che sia installato, se non lo e' lo installo
|
||||
;; N.B.: Se non si vuole averlo come dipendenza e' bene
|
||||
;; installarlo prima di use-package
|
||||
(unless (package-installed-p 'diminish)
|
||||
(unless package-archive-contents
|
||||
(package-refresh-contents))
|
||||
(package-install 'diminish))
|
||||
|
||||
;; Mi accerto che use-package sia installato
|
||||
;; se non lo e' lo installo
|
||||
(unless (package-installed-p 'use-package)
|
||||
(unless package-archive-contents
|
||||
(package-refresh-contents))
|
||||
(package-install 'use-package))
|
||||
|
||||
;; Carico use-package
|
||||
(eval-when-compile
|
||||
(require 'use-package))
|
||||
|
||||
;; Configuro use-package prima di caricarlo
|
||||
(eval-and-compile
|
||||
(if init-file-debug
|
||||
(setq use-package-verbose t
|
||||
use-package-expand-minimally nil
|
||||
use-package-compute-statistics t
|
||||
debug-on-error t) ; True
|
||||
(setq use-package-verbose nil
|
||||
use-package-expand-minimally t) ; False
|
||||
)
|
||||
(setq use-package-enable-imenu-support t
|
||||
;; Quanto segue e' MOLTO IMPORTANTE:
|
||||
;; Usare sempre gli hook con il loro nome completo
|
||||
;; al posto del nome abbreviato:
|
||||
;; after-init --> after-init-hook
|
||||
;; Questo migliora la gestione della documentazione
|
||||
;; a riconoscere il contesto (vedi, ad esempio 'describe-symbol)
|
||||
use-package-hook-name-suffix nil)
|
||||
)
|
||||
|
||||
;; Configuro vc (package gestione "version cotrol"
|
||||
(use-package vc
|
||||
:config
|
||||
;; Questo perche' i miei "dotfiles" usano i link simbolici
|
||||
(setq vc-follow-symlinks t)
|
||||
)
|
||||
|
||||
;; Carico org
|
||||
(use-package org
|
||||
;; Accertarsi di caricare quello presente nel repository GNU
|
||||
;; e non quello "builtin": quello in GNU e' sempre aggiornato.
|
||||
:pin gnu
|
||||
:ensure org
|
||||
)
|
||||
|
||||
;; Qui avviene la magia.
|
||||
;; Carico la configurazione dal file "org"
|
||||
;; Cerco pero' di ottimizzare un mimino la cosa:
|
||||
;; se il file "el" generato da org-babel e' piu' recente
|
||||
;; del file "org" allora carico "el" altrimenti passo
|
||||
;; all'uso di org-babel
|
||||
(progn (defvar gb/emacs/gb-init "gb-init")
|
||||
(defvar gb/emacs/conf-filename (expand-file-name gb/emacs/gb-init user-emacs-directory))
|
||||
(defvar gb/emacs/el-conf-filename (concat gb/emacs/conf-filename ".el"))
|
||||
(defvar gb/emacs/org-conf-filename (concat gb/emacs/conf-filename ".org"))
|
||||
(if (file-exists-p gb/emacs/el-conf-filename)
|
||||
(if (file-newer-than-file-p gb/emacs/org-conf-filename gb/emacs/el-conf-filename)
|
||||
(progn (message "%s e' piu' recente di %s, ricreo e carico il .el"
|
||||
gb/emacs/org-conf-filename
|
||||
gb/emacs/el-conf-filename)
|
||||
(org-babel-load-file gb/emacs/org-conf-filename))
|
||||
(progn (message "%s e' meno recente di %s, carico il .el senza ricrearlo"
|
||||
gb/emacs/org-conf-filename
|
||||
gb/emacs/el-conf-filename)
|
||||
(load-file gb/emacs/el-conf-filename)))
|
||||
(progn (message "Creo e carico %s" gb/emacs/el-conf-filename)
|
||||
(org-babel-load-file gb/emacs/org-conf-filename))
|
||||
)
|
||||
)
|
||||
|
||||
;; NON RIMUOVERE CUSTOM DA QUI
|
||||
;; ---------------------------
|
||||
;; Si potrebbe cedere alla tentazione di avere un init.el piu' "pulito"
|
||||
;; spostando custom-set-variables e custom-set-faces in un file separato,
|
||||
;; ma questo porta spesso a comportamenti altalenanti: se si installa un
|
||||
;; package con use-package e la sua opzione :ensure, capita che il package
|
||||
;; venga installato, ma la variabile package-selected-packages non venga
|
||||
;; aggiornata correttamente portanto il package installato ad uno stato
|
||||
;; di "dependency" in list-packages con invito alla rimozione qualora questo
|
||||
;; non fosse effettivamente utilizzato anche come dipendenza da qualche altro
|
||||
;; package
|
||||
(custom-set-variables
|
||||
;; custom-set-variables was added by Custom.
|
||||
;; If you edit it by hand, you could mess it up, so be careful.
|
||||
;; Your init file should contain only one such instance.
|
||||
;; If there is more than one, they won't work right.
|
||||
'(package-selected-packages
|
||||
'(modus-themes dockerfile-mode cargo docker docker-compose-mode flycheck-rust impatient-mode simple-httpd yasnippet yasnippet-snippets org projectile company-go go-errcheck go-mode company-auctex auctex sql-indent markdown-mode csharp-mode powershell counsel-projectile ibuffer-projectile rainbow-delimiters smartparens flycheck-pos-tip flycheck highlight-indent-guides aggressive-indent pcre2el emms pdf-tools csv-mode pretty-mode elfeed-protocol elfeed-org elfeed-goodies elfeed company-restclient restclient treemacs-all-the-icons treemacs-projectile treemacs-magit treemacs git-timemachine gitattributes-mode gitignore-mode gitconfig-mode magit undo-tree origami company-quickhelp ace-window avy symon beacon htmlize org-edna org-bullets amx ivy-hydra all-the-icons-ivy-rich ivy-rich swiper hydra which-key dashboard minions doom-modeline base16-theme seti-theme moe-theme solarized-theme color-theme-sanityinc-tomorrow dracula-theme atom-one-dark-theme zerodark-theme gruvbox-theme monokai-theme zenburn-theme material-theme spacemacs-theme doom-themes all-the-icons-ibuffer all-the-icons-dired all-the-icons async use-package diminish delight)))
|
||||
(custom-set-faces
|
||||
;; custom-set-faces was added by Custom.
|
||||
;; If you edit it by hand, you could mess it up, so be careful.
|
||||
;; Your init file should contain only one such instance.
|
||||
;; If there is more than one, they won't work right.
|
||||
)
|
||||
|
||||
;; ===========================================================================
|
||||
;; Local Variables:
|
||||
;; coding: utf-8-unix
|
||||
;; indent-tabs-mode: nil
|
||||
;; tab-width: 4
|
||||
;; End:
|
||||
;; ===========================================================================
|
||||
|
||||
;;; init.el ends here
|
||||
|
|
@ -0,0 +1,2 @@
|
|||
* text=auto
|
||||
pre-commit text eol=lf
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
#!/bin/bash
|
||||
|
||||
function get_org_of_current_repo() {
|
||||
local orgs_from_global_config=$(git config --get-regexp ^orgs. | cut -d . -f 2)
|
||||
|
||||
for org in $orgs_from_global_config; do
|
||||
local org_remotes=$(git remote -v | grep -i $org/)
|
||||
|
||||
if [ ! -z "$org_remotes" ]; then
|
||||
echo $org
|
||||
fi
|
||||
done
|
||||
}
|
||||
|
||||
|
||||
org=$(get_org_of_current_repo)
|
||||
|
||||
if [ ! -z "$org" ]; then
|
||||
organization_email=$(git config orgs\.$org\.email)
|
||||
repository_email=$(git config --local user.email)
|
||||
|
||||
if [ "$organization_email" != "$repository_email" ]; then
|
||||
echo "Organization '$org' identified!"
|
||||
echo "Setting the configured e-mail <$organization_email>"
|
||||
git config --local user.email $organization_email
|
||||
|
||||
echo "Please repeat the commit command to use the new e-mail"
|
||||
exit 1
|
||||
fi
|
||||
fi
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
[core]
|
||||
editor = vi
|
||||
quotepath = false
|
||||
[alias]
|
||||
graph = log --decorate --oneline --graph
|
||||
whatsnew = !git log ..origin/`git rev-parse --abbrev-ref HEAD`
|
||||
[include]
|
||||
path = ~/.gitconfig_user
|
||||
path = ~/.gitconfig_include
|
||||
[init]
|
||||
templatedir = ~/.git_template
|
||||
[pull]
|
||||
rebase = false
|
||||
[fetch]
|
||||
prune = false
|
||||
[rebase]
|
||||
autoStash = false
|
||||
|
||||
# vim: set ft=gitconfig :
|
||||
|
|
@ -0,0 +1,99 @@
|
|||
# -*- mode: gitignore; -*-
|
||||
#
|
||||
# https://www.toptal.com
|
||||
#
|
||||
# ------------------------------------------------------------------------
|
||||
# WINDOWS gitignore settings
|
||||
# ------------------------------------------------------------------------
|
||||
# Windows image file caches
|
||||
Thumbs.db
|
||||
ehthumbs.db
|
||||
# Folder config file
|
||||
Desktop.ini
|
||||
# Recycle Bin used on file shares
|
||||
$RECYCLE.BIN/
|
||||
# Windows Installer files
|
||||
*.cab
|
||||
*.msi
|
||||
*.msm
|
||||
*.msp
|
||||
# Windows shortcuts
|
||||
*.lnk
|
||||
# ------------------------------------------------------------------------
|
||||
|
||||
# ------------------------------------------------------------------------
|
||||
# EMACS gitignore settings
|
||||
# ------------------------------------------------------------------------
|
||||
*~
|
||||
\#*\#
|
||||
/.emacs.desktop
|
||||
/.emacs.desktop.lock
|
||||
*.elc
|
||||
auto-save-list
|
||||
tramp
|
||||
.\#*
|
||||
|
||||
# Org-mode
|
||||
.org-id-locations
|
||||
*_archive
|
||||
ltximg/**
|
||||
|
||||
# flymake-mode
|
||||
*_flymake.*
|
||||
|
||||
# eshell files
|
||||
/eshell/history
|
||||
/eshell/lastdir
|
||||
|
||||
# elpa packages
|
||||
/elpa/
|
||||
|
||||
# reftex files
|
||||
*.rel
|
||||
|
||||
# AUCTeX auto folder
|
||||
/auto/
|
||||
|
||||
# cask packages
|
||||
.cask/
|
||||
dist/
|
||||
|
||||
# Flycheck
|
||||
flycheck_*.el
|
||||
|
||||
# server auth directory
|
||||
/server/
|
||||
|
||||
# projectiles files
|
||||
.projectile
|
||||
|
||||
# directory configuration
|
||||
.dir-locals.el
|
||||
|
||||
# network security
|
||||
/network-security.data
|
||||
# ------------------------------------------------------------------------
|
||||
|
||||
# ------------------------------------------------------------------------
|
||||
# VIM gitignore settings
|
||||
# ------------------------------------------------------------------------
|
||||
# Swap
|
||||
[._]*.s[a-v][a-z]
|
||||
!*.svg # comment out if you don't need vector files
|
||||
[._]*.sw[a-p]
|
||||
[._]s[a-rt-v][a-z]
|
||||
[._]ss[a-gi-z]
|
||||
[._]sw[a-p]
|
||||
|
||||
# Session
|
||||
Session.vim
|
||||
Sessionx.vim
|
||||
|
||||
# Temporary
|
||||
.netrwhist
|
||||
*~
|
||||
# Auto-generated tag files
|
||||
tags
|
||||
# Persistent undo
|
||||
[._]*.un~
|
||||
# ------------------------------------------------------------------------
|
||||
|
|
@ -0,0 +1 @@
|
|||
* text eol=lf
|
||||
|
|
@ -0,0 +1,136 @@
|
|||
set nocompatible
|
||||
|
||||
if has("gui_running")
|
||||
let do_syntax_sel_menu=1
|
||||
endif
|
||||
|
||||
set langmenu=none
|
||||
if has("win32") || has("win64")
|
||||
language messages en_US
|
||||
else
|
||||
language messages en_US.UTF-8
|
||||
endif
|
||||
|
||||
if has("multi_byte")
|
||||
if has("win32") || has("win64")
|
||||
if has("gui_running")
|
||||
set encoding=utf-8
|
||||
endif
|
||||
endif
|
||||
set encoding=utf-8
|
||||
endif
|
||||
|
||||
set nocompatible
|
||||
|
||||
" set modeline
|
||||
|
||||
set backspace=indent,eol,start
|
||||
|
||||
" Highlight problematic whitespace
|
||||
" set listchars=tab:>.,trail:.,extends:#,nbsp:.
|
||||
" set listchars=eol:¶,tab:»,trail:·,extends:>,precedes:<,nbsp:¤
|
||||
" il carattere per eol (¶) si ottiene con CTRL-vu00b6
|
||||
" il carattere per tab (») si ottiene con CTRL-vu00bb
|
||||
" seguito da \<spazio> oppure
|
||||
" il carattere per trail (·) si ottiene con CTRL-vu00b7
|
||||
" il carattere per extends (>) e' il carattere di maggiore
|
||||
" il carattere per precedes (<) e' il carattere di minore
|
||||
" il carattere per nbsp (¤) si ottiene con CTRL-vu00a4
|
||||
set listchars=eol:¶,tab:»\ ,trail:·,extends:>,precedes:<,nbsp:¤
|
||||
|
||||
set number
|
||||
set relativenumber
|
||||
set history=50
|
||||
set incsearch
|
||||
set ignorecase
|
||||
set smartcase
|
||||
set wrapscan
|
||||
|
||||
" Make the 'cw' and like commands put a $ at the end instead of
|
||||
" just deleting the text and replacing it
|
||||
set cpoptions=ces$
|
||||
|
||||
set statusline=%<%F\ %h%m%r%w%q\ %y\(%{&ff}\)\ %=\ \#%n\ ln:%l\/%L[%P]\ co:%c%V\ %b
|
||||
|
||||
set lazyredraw
|
||||
set showmode
|
||||
set foldenable
|
||||
set foldopen=block,insert,jump,mark,percent,quickfix,search,tag,undo
|
||||
set whichwrap=b,s,h,l,<,>,[,]
|
||||
set scrolljump=0
|
||||
set scrolloff=0
|
||||
set sidescrolloff=0
|
||||
set wildmenu
|
||||
set showfulltag
|
||||
set diffopt+=iwhite
|
||||
set clipboard+=unnamed
|
||||
set grepprg=grep\ -nH\ $*
|
||||
|
||||
" let loaded_matchparen=1
|
||||
|
||||
set showtabline=2
|
||||
set nostartofline
|
||||
set nospell " spell checking off (default!)
|
||||
if has("autocmd")
|
||||
filetype plugin indent on
|
||||
augroup vimrcEx
|
||||
au!
|
||||
autocmd BufReadPost *
|
||||
\ if line("'\"") > 1 && line("'\"") <= line("$") |
|
||||
\ exe "normal! g`\"" |
|
||||
\ endif
|
||||
augroup END
|
||||
|
||||
endif " has("autocmd")
|
||||
|
||||
set nowrap
|
||||
set autoindent
|
||||
set tabstop=4
|
||||
set shiftwidth=4
|
||||
set softtabstop=4
|
||||
set noexpandtab
|
||||
|
||||
if has("mouse")
|
||||
set mouse=a
|
||||
endif
|
||||
|
||||
if &t_Co > 2 || has("gui_running")
|
||||
syntax enable
|
||||
set hlsearch
|
||||
set synmaxcol=2048
|
||||
endif
|
||||
|
||||
if has("cmdline_info")
|
||||
set noruler
|
||||
set showcmd
|
||||
endif
|
||||
|
||||
if has("statusline")
|
||||
set laststatus=2
|
||||
set statusline=%<%f\ " Filename
|
||||
set statusline+=%w%h%m%r " Options
|
||||
set statusline+=\ [%{&ff}/%Y] " filetype
|
||||
set statusline+=\ [%{getcwd()}] " current dir
|
||||
"set statusline+=\ [A=\%03.3b/H=\%02.2B] " ASCII / Hexadecimal value of char
|
||||
set statusline+=%=%-14.(%l,%c%V%)\ %p%% " Right aligned file nav info
|
||||
endif
|
||||
|
||||
if has("gui_running")
|
||||
" GUI
|
||||
set cursorline
|
||||
set guicursor=n-v-c:block-Cursor-blinkon0,ve:ver35-Cursor,o:hor50-Cursor,i-ci:ver25-Cursor,r-cr:hor20-Cursor,sm:block-Cursor-blinkwait175-blinkoff150-blinkon175
|
||||
set cmdheight=2 " Abbreviato: set ch=2
|
||||
set mousehide
|
||||
endif
|
||||
|
||||
set shortmess+=I
|
||||
|
||||
" CTRL-U in insert mode deletes a lot. Use CTRL-G u to first break undo,
|
||||
" so that you can undo CTRL-U after inserting a line break.
|
||||
inoremap <C-U> <C-G>u<C-U>
|
||||
|
||||
set background=dark
|
||||
|
||||
"
|
||||
" vim: set tabstop=4:shiftwidth=4:filetype=vim:fdm=marker:fileformat=unix:
|
||||
"
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
#!/usr/bin/env bash
|
||||
echo "Per eliminare l'utente usare : 'userdel -r <username>'"
|
||||
echo "Per creare l'utente usare : 'useradd -m <username>'"
|
||||
echo "Per impostare la password usare: 'passwd'"
|
||||
echo ""
|
||||
echo "Se quando si elimina l'utente non viene eliminata anche la \$HOME"
|
||||
echo "puo' dipendere dal fatto che esistono processi in esecuzione'"
|
||||
echo "lanciati dall'utente, userdel lo dice."
|
||||
echo ""
|
||||
echo ""
|
||||
if [ $(id -u) -eq 0 ]; then
|
||||
USN="sdf"
|
||||
USP="sdf"
|
||||
egrep "^$USN" /etc/passwd >/dev/null
|
||||
if [ $? -eq 0 ]; then
|
||||
echo "Sto per eliminare l'utente $USN"
|
||||
userdel -r $USN
|
||||
echo "Ho eliminato l'utente $USN"
|
||||
else
|
||||
echo "L'utente $USN non esiste ancora"
|
||||
fi
|
||||
echo "Proseguo con la creazione dell'utente $USN"
|
||||
useradd -m $USN
|
||||
echo $USN:$USP | chpasswd
|
||||
echo "Utente $USN aggiunto al sistema"
|
||||
else
|
||||
echo "Script eseguile soltanto come root!!!"
|
||||
exit 2
|
||||
fi
|
||||
|
|
@ -0,0 +1,142 @@
|
|||
* Chezmoi
|
||||
|
||||
E' 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,
|
||||
ma anche su Windows.
|
||||
|
||||
* La filosofia
|
||||
|
||||
Chezmoi si differenzia un po' dal resto degli strumenti in quanto tende a non usare i link simbolici
|
||||
ma una "copia" dei files.
|
||||
|
||||
* Installazione
|
||||
|
||||
Sul sito github di Chezmoi c'è un comando da copiare che consente l'installazione del programma
|
||||
(e anche la clonazione del repository).
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
** Prima installazione con repository da creare
|
||||
|
||||
Se non diversamente indicato lo script di installazione posiziona il programma nella ~$HOME/.bin~,
|
||||
posizione che a me non piace particolarmente; preferisco che l'eseguibile venga posizionato nella
|
||||
~$HOME/.local/bin~ che un po' tutte le versioni recenti di Linux hanno già nel path.
|
||||
|
||||
Per installare il programma nella ~$HOME/.local/bin~ occorre eseguire quindi il comando così modificato:
|
||||
#+begin_example
|
||||
sh -c "$(curl -fsLS git.io/chezmoi)" -- -b $HOME/.local/bin
|
||||
#+end_example
|
||||
|
||||
** Installazione con clone del repository esistente
|
||||
|
||||
Qui la situazione è praticamente quella descritta nella documentazione.
|
||||
|
||||
L'unica differenza continua ad essere la preferenza personale nel voler installare l'eseguibile
|
||||
nella ~$HOME/.local/bin~
|
||||
|
||||
Assumendo che il repository sia su Github:
|
||||
#+begin_example
|
||||
sh -c "$(curl -fsLS git.io/chezmoi)" -- -b $HOME/.local/bin init --apply <github-username>
|
||||
#+end_example
|
||||
|
||||
La connessione al repository avviene normalmente usando il protocollo HTTPS, è possibile usare
|
||||
il protocollo SSH usando il parametro aggiuntivo ~--ssh~.
|
||||
|
||||
Il pattern ~<github-username>~ può assumere, secondo la documentazione:
|
||||
|
||||
| Pattern | HTTPS Repo | SSH repo |
|
||||
|------------------+--------------------------------------+----------------------------------|
|
||||
| user | https://github.com/user/dotfiles.git | git@github.com:user/dotfiles.git |
|
||||
| user/repo | https://github.com/user/repo.git | git@github.com:user/repo.git |
|
||||
| site/user/repo | https://site/user/repo.git | git@site:user/repo.git |
|
||||
| ~sr.ht/user | https://git.sr.ht/~user/dotfiles | git@git.sr.ht:~user/dotfiles.git |
|
||||
| ~sr.ht/user/repo | https://git.sr.ht/~user/repo | git@git.sr.ht:~/user/repo.git |
|
||||
|
||||
* Partendo da un repository esistente
|
||||
|
||||
Una volta installato il programma e clonato il repository l'unica azione da eseguire per avere
|
||||
la configurazione dei dotfiles funzionante è:
|
||||
|
||||
#+begin_example
|
||||
chezmoi apply
|
||||
#+end_example
|
||||
|
||||
E' possibile aggiungere al comando dei parametri, tra questi sono utili:
|
||||
- ~-v~ :: verbose, mostra il dettaglio delle operazioni effettuate
|
||||
- ~-n~ :: dry-run, esegue un "giro di prova" senza applicare effettivamente le modifiche
|
||||
|
||||
* Aggiunta di elementi alla gestione
|
||||
|
||||
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
|
||||
possiamo fare:
|
||||
|
||||
** Emacs
|
||||
|
||||
Con questi comandi si aggiungo in files e le directories alla gestione
|
||||
|
||||
#+begin_example
|
||||
chezmoi add ~/.emacs.d/early-init.el
|
||||
chezmoi add ~/.emacs.d/init.el
|
||||
chezmoi add ~/.emacs.d/gb-init.org
|
||||
chezmoi add ~/.emacs.d/img
|
||||
chezmoi add ~/.emacs.d/snippets
|
||||
#+end_example
|
||||
|
||||
Per vedere le modifiche che chezmoi applicherà si può usare il comando
|
||||
|
||||
#+begin_example
|
||||
chezmoi diff
|
||||
#+end_example
|
||||
|
||||
Per applicare le modifiche:
|
||||
|
||||
#+begin_example
|
||||
chezmoi -v apply
|
||||
#+end_example
|
||||
|
||||
A questo punto abbiamo operato le varie modifiche al repository locale. Chezmoi non interagisce
|
||||
direttamente con git, per cui occorre entrare nella directory del repository ed eseguire sia il commit
|
||||
che il push:
|
||||
|
||||
#+begin_example
|
||||
chezmoi cd # apre una shell posizionandosi nella directory del repository
|
||||
git add . # aggingiamo il tutto allo sage
|
||||
git commit -m "Aggiunto Emacs"
|
||||
exit # esce dalla shell creata da chezmoi
|
||||
#+end_example
|
||||
|
||||
Per aggiornare poi il repository remoto:
|
||||
|
||||
#+begin_example
|
||||
chezmoi cd
|
||||
git push origin master
|
||||
exit
|
||||
#+end_example
|
||||
|
||||
** Vim
|
||||
|
||||
#+begin_example
|
||||
chezmoi add ~/.vimrc
|
||||
chezmoi add ~/.vim
|
||||
chezmoi -v apply
|
||||
chezmoi cd
|
||||
git add .
|
||||
git commit -m "Aggiunto Vim"
|
||||
git push origin master
|
||||
exit
|
||||
#+end_example
|
||||
|
||||
** Git
|
||||
|
||||
Nel repository di esempio si è usato il meccanimso dei template per configurare l'utente di Git
|
||||
(in .gitconfig) in base all'hostname.
|
||||
|
||||
|
|
@ -0,0 +1,195 @@
|
|||
* Dotbot
|
||||
|
||||
Si tratta di uno strumento simile a GNU Stow ma che rispetto a questo
|
||||
presenta delle migliorie.
|
||||
|
||||
Come Stow anche Dotbot funziona soltanto su Linux/MacOS. E' scritto
|
||||
in Python che, almeno sulle macchine Linux, è solitamente preinstallato.
|
||||
|
||||
La metodologia standard per l'uso di Dotbot consiste nel creare un
|
||||
repository per contenere i dotfiles e, all'interno di questo, clonare
|
||||
come submodule Dotbot stesso. Questo sistema rende tutta la gestione
|
||||
in qualche modo "self contained" mentre Stow, ad esempio, deve essere
|
||||
installato.
|
||||
|
||||
La pagine di riferimento per il progetto su Github è:
|
||||
[[https://github.com/anishathalye/dotbot][https://github.com/anishathalye/dotbot]] dove si trova anche la documentazione
|
||||
|
||||
* Partendo da zero
|
||||
|
||||
Se si inizia a lavorare con Dotbot partendo da zero occorre creare un
|
||||
nuovo repository che andrà a contenere i files da gestire, assumiamo
|
||||
che il repository si troverà nella directory ~$HOME/.dotfiles~ e che
|
||||
questa sia già stata creata:
|
||||
|
||||
#+begin_example
|
||||
# Mi posiziono nella directory del repository
|
||||
cd ~/.dotfiles
|
||||
# Inizializzo il repository se non esiste
|
||||
git init
|
||||
# Aggiungo dotbot come submodule
|
||||
git submodule add https://github.com/anishathalye/dotbot
|
||||
# Dico a git di ignorare eventuali modifiche alla workdir del submodule
|
||||
git config -f .gitmodules submodule.dotbot.ignore dirty
|
||||
# Copio il comando di "install" dal submodule nella root del repository
|
||||
cp dotbot/tools/git-submodule/install .
|
||||
# Creo il file di configurazione (vuoto)
|
||||
touch install.conf.yaml
|
||||
#+end_example
|
||||
|
||||
A questo punto non si deve fare altro che iniziare a impostare il
|
||||
contenuto di ~install.conf.yaml~ e spostare i dotfiles dalla posizione
|
||||
origine all'interno del repository.
|
||||
|
||||
Una volta impostato il tutto il comando ~install~ provvederà alla
|
||||
creazione dei link.
|
||||
|
||||
* Il file ~install.conf.yaml~
|
||||
|
||||
E' il motore di tutto il procedimento. E' un file in formato [[https://it.wikipedia.org/wiki/YAML][YAML]] e come tale necessita
|
||||
di una corretta gestione dell'indentazione delle righe.
|
||||
Dotbot consente anche l'uso del formato [[https://www.json2yaml.com/][JSON]], in questo caso il file si dovrà
|
||||
chiare ~install.conf.json~
|
||||
|
||||
~install.conf.yaml~ è suddiviso in "comandi":
|
||||
- Defaults :: Qui vanno le impostazioni di default valide per tutte la varie
|
||||
situazioni. E' utile per non dover specificare le stesse impostazioni
|
||||
in ogni singolo altro ramo.
|
||||
- Link :: Contiene, in forma di dizionario, gli abbinamenti tra destinazione
|
||||
e origine. L'origine è il file presente nel repository e deve essere
|
||||
specificato sempre relativamente alla radice del repository stesso (che
|
||||
è dove si sta eseguendo l'installer).
|
||||
Se si creano link a directory si deve omettere la barra finale.
|
||||
- Create :: Indica le directory che devono essere create. Utile per creare
|
||||
la struttura che poi andrà a contenere i link o che comunque è richiesta
|
||||
dalle varie applicazioni.
|
||||
- Shell :: Specifica i comandi di shell da eseguire. I comandi eseguiti
|
||||
fanno riferimento alla directory in cui l'installer viene eseguito.
|
||||
- Clean :: Specifica le directory che dovranno essere esaminate per la
|
||||
presenza di "dead links". Nel caso in cui si trovi la presenza di un
|
||||
link simbolico che non porta a niente questo viene eliminato.
|
||||
|
||||
Ciascun "comando" prevede vari parametri, vedere la documentazione di Dotbot
|
||||
per approfondire.
|
||||
|
||||
* Impostiamo la gestione
|
||||
|
||||
Con un editor andiamo a descrivere le opzioni di installazione in ~install.conf.yaml~
|
||||
|
||||
** Le impostazioni di default
|
||||
|
||||
Le impostazioni di default sono quelle che, una volta specificate, valgono per
|
||||
tutti gli altri "comandi". Nello specifico vogliamo che ciascun link utilizzi
|
||||
l'opzione "relink" che rimuove il vecchio target se è un link simbolico.
|
||||
|
||||
#+begin_example
|
||||
- defaults:
|
||||
link:
|
||||
relink: true
|
||||
#+end_example
|
||||
|
||||
** Facciamo rimuovere i "dead link"
|
||||
|
||||
Con l'opzione ~clean~ si indicano le directory in cui deve avvenire un
|
||||
controllo per la verifica dei dead link verso il repository.
|
||||
|
||||
#+begin_example
|
||||
- clean: ['~']
|
||||
#+end_example
|
||||
|
||||
** Impostiamo la creazione dei link simbolici
|
||||
|
||||
#+begin_example
|
||||
- link:
|
||||
~/.emacs.d: emacs/.emacs.d
|
||||
~/.vim: vim/.vim
|
||||
~/.vimrc: vim/.vimrc
|
||||
#+end_example
|
||||
|
||||
Nell'esmpio 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.
|
||||
|
||||
L'impostazione che ho dato è quella di avere nel repository delle directory
|
||||
che andranno a contenere tutti gli elementi di una applicazione.
|
||||
|
||||
In questo semplice esempio si sono creati i soli link simbolici non sfruttando
|
||||
le possibilità di creare directory, eseguire script o utilizzare plugins.
|
||||
|
||||
** Il risultato finale
|
||||
|
||||
Il risultato finale del contenuto di ~install.conf.yaml~ dovrebbe quindi essre:
|
||||
|
||||
#+begin_example
|
||||
- defaults:
|
||||
link:
|
||||
relink: true
|
||||
|
||||
- clean: ['~']
|
||||
|
||||
- link:
|
||||
~/.emacs.d: emacs/.emacs.d
|
||||
~/.vim: vim/.vim
|
||||
~/.vimrc: vim/.vimrc
|
||||
#+end_example
|
||||
|
||||
** Copiamo nel repository
|
||||
|
||||
A questo punto dobbiamo spostare nel repository i files e le directory.
|
||||
|
||||
Occorre spostare la directory ~$HOME/.emacs.d~ in ~$HOME/.dotfiles/emacs/~
|
||||
|
||||
Occorre anche spostare sia il file ~$HOME/.vimrc~ che la directory
|
||||
~$HOME/vim~ in ~$HOME/.dotfiles/vim/~
|
||||
|
||||
** Commit & push
|
||||
|
||||
Stiamo lavorando in un repository. Non dimentichiamo di fare commit e push!
|
||||
|
||||
** Install
|
||||
|
||||
Una volta configurato il tutto non resta che far lavorare dotbot.
|
||||
|
||||
Con il comando ~install~ (presente in ~$HOME/.dotfiles~) saranno creati i
|
||||
link simbolici e fatto tutto quanto indicato nel file di configurazione.
|
||||
|
||||
* Bootstrap
|
||||
|
||||
Una volta creato il repository, configurato e messo su di un server raggiungibile
|
||||
il bootstrap in un ambiente nuovo si riduce ad una linea di codice:
|
||||
#+begin_example
|
||||
cd ~ && git clone https://url/to/git/server/.dotfiles && cd ~/.dotfiles && ./install
|
||||
#+end_example
|
||||
|
||||
L'esempio assume l'uso di un repository che si chiama ~.dotfiles~ che sarà clonato
|
||||
nella ~$HOME~ mantenendo lo stesso nome.
|
||||
|
||||
*CAVEAT*
|
||||
|
||||
Dotbot NON crea i link simbolici se il target già esiste come file o directroy normale.
|
||||
Eventuali link simbolici esistenti sono sostituiti in presenza della direttiva ~relink: true~
|
||||
|
||||
* Informazioni aggiuntive
|
||||
|
||||
** Plugins
|
||||
|
||||
Una caratteristica interessante di dotbot è quella di avere un'architettura
|
||||
che consente l'uso di plugins.
|
||||
|
||||
Tra i plugins disponibili ([[https://github.com/anishathalye/dotbot/wiki/Plugins][https://github.com/anishathalye/dotbot/wiki/Plugins]])
|
||||
si trovano, ad esempio, quelli per clonare repository git, per installare
|
||||
Visual studo code, per installare Rust.
|
||||
|
||||
La lista non è enorme, ma comprende comunque elementi utili.
|
||||
|
||||
** Repository di esempio
|
||||
|
||||
Oltre all'autore del software che nel suo spazio su Github rende disponibile
|
||||
la propria gestione dotfiles, nelle pagine Wiki del progetto si trova una
|
||||
(lunga) [[https://github.com/anishathalye/dotbot/wiki/Users][lista di utenti che gestiscono i propri dotfiles con dotbot]]
|
||||
|
||||
** Tips-And-Tricks
|
||||
|
||||
Nella pagina wiki [[https://github.com/anishathalye/dotbot/wiki/Tips-and-Tricks][tips & triks]] del progetto si trovano spunti interessanti
|
||||
sia per risolvere situazioni particolari, ma anche come punti di partenza
|
||||
per approfondire ulteriori argomenti correlati alla gestione dei dotfiles.
|
||||
|
|
@ -0,0 +1,118 @@
|
|||
* Gestire i dotfiles con GNU Stow
|
||||
|
||||
GNU Stow è uno strumento nato per gestire in modo massivo
|
||||
i link simbolici nell'installazione di pacchetti software
|
||||
compilati dai sorgenti.
|
||||
|
||||
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.
|
||||
|
||||
* I "package"
|
||||
|
||||
Stow definisce come package delle collezioni di elementi
|
||||
correlati allo stesso contesto e che si vogliono gestire
|
||||
come elemento unitario. Un package è una directory che
|
||||
contiene al suo interno tutta la struttura che si vuole
|
||||
replicare.
|
||||
|
||||
Il package "vim" (quindi la directory "vim") conterrà tutti
|
||||
i files e le directory necessari per la configurazione di
|
||||
vim. Il nome del package non è necessariamente lo stesso
|
||||
del programma di cui andremo a gestire i dotfiles, ma è
|
||||
sicuramente buona pratica dare dei nomi significativi.
|
||||
|
||||
* La "stow directory"
|
||||
|
||||
E' la directory che contiene i package che vogliamo
|
||||
gestire.
|
||||
|
||||
Se non indicato in modo esplicito Stow considera come
|
||||
stow directory la directory corrente.
|
||||
|
||||
* La "target directory"
|
||||
|
||||
E' la directory di destinazione dove Stow andrà a creare
|
||||
i link simbolici. Se non indicata in modo esplicito
|
||||
Stow assume come target directory la parent della
|
||||
directory corrente.
|
||||
|
||||
* Creazione della struttura.
|
||||
|
||||
Assumendo che la stow directory si chiami ".dotfile"
|
||||
un esempio di struttura potrebbe essere questo:
|
||||
|
||||
#+begin_example
|
||||
$HOME
|
||||
+-- .dotfiles
|
||||
+ bash (directory - package)
|
||||
| +-- .bash_aliases (file)
|
||||
+-- vim (directory - package)
|
||||
| +-- .vim (directory)
|
||||
| +-- .vimrc (file)
|
||||
+-- htop (directory - package)
|
||||
+-- .config (directory)
|
||||
+-- htop (directory)
|
||||
+-- htoprc (file)
|
||||
#+end_example
|
||||
|
||||
* Esecuzione
|
||||
|
||||
~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~
|
||||
|
||||
E' possibile indicare più package: ~stow bash htop~ creerà i link simbolici per
|
||||
i package "bash" e "htop".
|
||||
|
||||
E' possibile anche far girare stow per tutti i package della stow directory:
|
||||
~stow *~
|
||||
|
||||
* ~--adopt~
|
||||
|
||||
Un parametro estremamente utile, ma da usare con cautela è ~--adopt~.
|
||||
|
||||
Una volta creata la struttura dei package dove i files possono essere vuoti, si
|
||||
può utilizzare questa opzione per automatizzare lo spostamento del file effettivo
|
||||
nella sua posizione del package e la creazione del link simbolico.
|
||||
|
||||
Quindi, assumendo di aver creato la struttura e che nel package "bash" il file
|
||||
~bash_aliases~ sia presente ma vuoto e assumendo anche che esista il file
|
||||
~$HOME/.bash_aliases~, l'uso del comando ~stow --adopt bash~ andrà a spostare
|
||||
il file ~$HOME/.bash_aliases~ nella ~$HOME/.dotfiles/bash~ sovrascrivendo
|
||||
il file esistente e creerà un link simbolico che vi punta.
|
||||
a spostare
|
||||
|
||||
* Rimozione dei link simbolici
|
||||
|
||||
Può capitare di voler far pulizia: è possibile rimuovere i link simbolici
|
||||
creati usando il parametro ~-D~
|
||||
|
||||
* Configurazioni separate per macchine separate
|
||||
|
||||
E' un funzionalità non gestità 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~
|
||||
|
||||
E' possibile creare una struttura simile a questa:
|
||||
|
||||
#+begin_example
|
||||
$HOME
|
||||
+-- .dotfiles
|
||||
+-- bash (directory - package)
|
||||
+-- PC1 (directory - macchina 1)
|
||||
| +-- .bash_aliases (file per macchina 1)
|
||||
+-- PC2 (directory - macchina 2)
|
||||
+-- .bash_aliases (file per macchina 2)
|
||||
#+end_example
|
||||
|
||||
A questo punto si dovrà indicare a Stow che, per la macchina 1, la stow directory
|
||||
è la ~$HOME/.dotfiles/bash~ e che la target directory è la ~$HOME~.
|
||||
|
||||
Il comando sarà quindi qualcosa di simile (usando il parametro ~-n~ per simulare
|
||||
l'esecuzione:
|
||||
~stow -n -d $HOME/.dotfiles/bash -t $HOME PC1~
|
||||
|
||||
|
|
@ -0,0 +1,90 @@
|
|||
* Gestione della ~$HOME~ direttamente come repository
|
||||
|
||||
E' un metodo che consiste nel fare in modo che il contenuto della $HOME
|
||||
sia gestito direttamente come un repository Git.
|
||||
|
||||
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.
|
||||
|
||||
Git consente infatti di indicare, tramite appositi parametri, sia la
|
||||
directory con i files da tracciare, sia la directory con i suoi dati.
|
||||
|
||||
Per evitare di ripetere ogni volta questi parametri e anche per evitare
|
||||
di sbagliarli si crea comunemente un alias.
|
||||
|
||||
* Il metodo di lavoro
|
||||
|
||||
** Creazione del repository "bare"
|
||||
|
||||
Il repository può essere creato da zero o clonato da un server
|
||||
remoto.
|
||||
|
||||
Per convenzione si utilizzerà un repository che localmente si chiama
|
||||
~.dotfiles~. Si assume che i comandi siano dati avendo la $HOME come
|
||||
directory corrente.
|
||||
|
||||
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 è:
|
||||
~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.
|
||||
|
||||
L'alias va reso disponibile ad ogni login, qui si aggiunge al
|
||||
~.bashrc~. Per aggiungerlo si può modiificare il file con un editor
|
||||
o accodarlo con i comandi di shell.
|
||||
|
||||
Per aggiungere l'alias accodandolo:
|
||||
~echo "alias dotfiles='/usr/bin/git --git-dir=$HOME/.dotfiles --work-tree=$HOME'" >> $HOME/.bashrc
|
||||
|
||||
** Configurazione del repository
|
||||
|
||||
Per evitare di vedere sempre come "non gestiti" tutti i files di cui non
|
||||
ci importa e che non devono andare nel repository occorre configurare Git
|
||||
in modo che non ce li mostri:
|
||||
~dotfiles config --local status.showUntrackedFiles no~
|
||||
|
||||
Infine, solo Se si è creato un nuovo repository e si intende appoggiare
|
||||
il tutto ad un server remoto occorre configurare il "remote":
|
||||
~dotfiles remote add <url>~
|
||||
|
||||
** Operatività:
|
||||
|
||||
A questo punto si usano i normali comandi Git avendo l'unica accortezza
|
||||
di usare ~dotfiles~ invece di ~git~
|
||||
|
||||
Alcuni esempi
|
||||
|
||||
*** Aggiuntere un nuovo file all'area di stage
|
||||
|
||||
~dotfiles add /path/to/file~
|
||||
|
||||
*** Commit
|
||||
|
||||
~dotfiles commit~
|
||||
|
||||
*** Push
|
||||
|
||||
~dotfiles pull~
|
||||
|
||||
** Caveats
|
||||
|
||||
Non è tutto oro quello che luccica.
|
||||
|
||||
Questo metodo rende complessa la gestione di files di configurazione di macchie
|
||||
diverse. Si può ricorrere all'uso delle branch per identificare la macchina, ma
|
||||
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
|
||||
repository bare.
|
||||
|
||||
~dotfiles reset --hard~ potrebbe causare un infarto.
|
||||
|
||||
"Varie ed eventuali".
|
||||
|
|
@ -0,0 +1,473 @@
|
|||
#+TITLE: Ora del GOLEM - i dotfiles
|
||||
#+SUBTITLE: Una gestione ragionata dei files di configurazione
|
||||
#+LANGUAGE: it
|
||||
#+DATE: 22/06/2021
|
||||
#+OPTIONS: toc:t
|
||||
#+LATEX_CLASS: article
|
||||
# #+LATEX_CLASS: report
|
||||
#+LATEX_HEADER: \usepackage[margin=1.5cm]{geometry}
|
||||
#+LATEX_CLASS_OPTIONS: [a4paper,12pt]
|
||||
#+LATEX_HEADER: \usepackage[italian]{babel}
|
||||
#+LATEX_HEADER: \usepackage[hyphenbreaks]{breakurl}
|
||||
|
||||
#+LATEX: \pagebreak
|
||||
|
||||
* 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
|
||||
limitatamente al solo utente.
|
||||
|
||||
La prima cosa ch viene in mente è usare uno script di shell, ma ovviamente non è un dogma.
|
||||
Girando in rete ho trovato questo video su Youtube dove viene mostrato un approccio basato su
|
||||
Make: [[https://www.youtube.com/watch?v=aP8eggU2CaU][How To Manage Your Dotfiles With Make]][fn:10]
|
||||
|
||||
** Uso strumenti già pronti
|
||||
|
||||
E' probabilmente la soluzione più semplice. In rete sono presenti molti strumenti che coprono con varie
|
||||
modalità le esigenza più comuni.
|
||||
|
||||
Se poi lo strumento scelto non fosse perfetto per noi possiamo sempre sfruttare i vantaggi messi a
|
||||
disposizione dal mondo dell'open source: proporre delle patch o fare un fork.
|
||||
|
||||
L'elenco degli strumenti reperibili in rete è discretamente lungo e in continuo aggiornamento.
|
||||
|
||||
Tra questi quelli che hanno in qualche modo attirato la mia attenzione quelli che:
|
||||
- Sono multi-piattaforma e oltre ai canonici Linux/Mac includono anche Windows.
|
||||
- Sono per quanto possibili esenti da dipendenze esterne intendendo questa affermazione in modo
|
||||
"lasco", nel senso che se le dipendenze sono normalmente presenti nel sistema e non devo
|
||||
installare niente allora va bene, ma va bene anche usare un singolo eseguibile che magari può
|
||||
essere inserito nel repository stesso.
|
||||
- Non soddisfano i criteri precedenti, ma appartengono comunque al gruppo dei più utlizzati in
|
||||
base ad una statistica veloce e non ortodossa risultante da qualche ricerca in rete.
|
||||
|
||||
*** GNU Stow
|
||||
|
||||
E' un software che nasce essenzialmente per gestire la creazione di link simbolici.
|
||||
E' nativo Linux e credo funzioni anche su Mac, ma non Windows.
|
||||
|
||||
Gode di una certa fama in quanto semplice ed immediato, ma si limita a fare una ed una sola cosa,
|
||||
anche se la fa bene.
|
||||
Con Stow, infatti, potete soltanto gestire i link simbolici.
|
||||
|
||||
Il funzionamento è appunto molto semplice: è sufficiente creare una directory in cui andare
|
||||
a creare tante sottodirectory quanti sono i "moduli" che vogliamo gestire. Questa semplicità
|
||||
rende più complicata la gestione di configurazioni diverse su macchine diverse. L'ostacolo si
|
||||
può in qualche modo aggirare con degli script, ma non si possono gestire parti in comune.
|
||||
|
||||
[[https://www.gnu.org/software/stow/][Link alla pagina del software]][fn:11]
|
||||
|
||||
*** dotbot
|
||||
|
||||
Uno "Stow on steroid" per forza di cose un po' più complesso, ma non troppo.
|
||||
|
||||
Scritto in Python consente la gestione dei dotfiles come link simbolici ma anche molto altro come,
|
||||
ad esempio, configurazioni separate per macchina/profilo o l'esecuzione di comandi. Da notare
|
||||
la possibilità di usare dei plug-in oltre al fatto che, dando per scontato la presenza di Python su
|
||||
tutte le installazioni Linux, la replica di una configurazione si limita ad una riga di bash.
|
||||
|
||||
Purtroppo non funziona in modo nativo in Windows.
|
||||
|
||||
Pur mantenendo una relativa semplicità offre molte funzionalità in più rispetto a Stow.
|
||||
|
||||
[[https://github.com/anishathalye/dotbot][Link alla pagina del software]][fn:12]
|
||||
[[https://github.com/anishathalye/dotfiles][I dotfiles dello sviluppatore]][fn:13]
|
||||
|
||||
*** Chezmoi
|
||||
|
||||
Scritto in GO - quindi senza dipendenze - funziona in ambiente Linux/Mac e Windows.
|
||||
|
||||
Usa un approccio diverso rispetto agli altri perché invece di usare dei link simbolici gestisce
|
||||
a livello applicativo i dotfiles.
|
||||
|
||||
Sulla carta offre capacità notevoli, tra cui il funzionamento in Windows. Ad una prima prova
|
||||
è però risultato poco confortevole, forse anche a causa di una documentazione che trovo poco
|
||||
chiara.
|
||||
|
||||
Occorre comunque tenere presente questo strumento che gode di molti giudizi positivi in rete.
|
||||
|
||||
[[https://github.com/twpayne/chezmoi][Link alla pagina del software]][fn:14]
|
||||
[[https://github.com/twpayne/dotfiles][I dotfiles dello sviluppatore]][fn:15]
|
||||
|
||||
*** Yadm
|
||||
|
||||
E' uno degli strumenti per la gestione dei dotfiles che si trovano più frequentemente nelle
|
||||
discussioni in rete.
|
||||
|
||||
Scritto in Python, funziona soltanto su Linux/Mac, ma offre molte funzionalità comunemente
|
||||
apprezzate quale la gestione sia di files specifici per sistema che l'uso di template.
|
||||
Apprezzabile la possibilità di crittografare dati sensibili.
|
||||
|
||||
[[https://yadm.io][Link alla pagina del software]][fn:16]
|
||||
|
||||
*** Toml-bombadil
|
||||
|
||||
Scritto in Rust, multi-piattaforma
|
||||
|
||||
Interessante progetto che prendendo come modello Chezmoi cerca di semplificarne
|
||||
un po' l'uso gestendo soltanto alcune funzionalità peculiari. A differenza di
|
||||
Chezmoi presenta una documentazione scritta discretamente e quindi facilmente
|
||||
comprensibile
|
||||
|
||||
[[https://github.com/oknozor/toml-bombadil][Link alla pagina del software]][fn:17]
|
||||
[[https://github.com/oknozor/dotfiles][I dotfiles dello sviluppatore]][fn:18]
|
||||
[[https://rgoswami.me/posts/dotfiles-dotgit-bombadil][L'esperienza d'uso di un utilizzatore]][fn:19]
|
||||
|
||||
*** Varie ed eventuali
|
||||
|
||||
Il mondo degli strumenti di ausilio alla gestione dei dotfiles è i continuo fermento e
|
||||
il loro numero aumenta quasi giornalmente, per cui è praticamente impossibile approfondire tutta
|
||||
la produzione disponibile.
|
||||
|
||||
Alcuni tra quelli trovati nelle varie ricerche in rete sono comunque degni di nota e da considerare,
|
||||
se non altro, per vedere come evolvono.
|
||||
|
||||
**** Homeshick
|
||||
|
||||
Completamente scritto in Bash - quindi senza dipendenze.
|
||||
|
||||
Un altro gestore di link simbolici.
|
||||
|
||||
[[https://github.com/andsens/homeshick][Link alla pagina del software]][fn:20]
|
||||
|
||||
**** Dotprop
|
||||
|
||||
Scritto in Python.
|
||||
|
||||
Offre alcune caratteristiche interessanti quali la possibilità di gestire configurazioni
|
||||
separate per macchina di destinazione e l'utilizzo di template per avere impostazioni
|
||||
differenti all'interno dello stesso dotfile.
|
||||
|
||||
[[https://github.com/deadc0de6/dotdrop][Link alla pagina del software]][fn:21]
|
||||
|
||||
**** Dotter
|
||||
|
||||
Un altro "Stow on steroid" che però offre alcuni importanti vantaggi:
|
||||
- E scritto in Rust: non ha dipendenze e funziona su tutte le piattaforme
|
||||
- Consente l'uso di template anche se files originati da template non sono link simbolici
|
||||
ma files veri e propri: se si deve modificare qualcosa occorre modificare il template
|
||||
e poi ricreare il dotfile con dotter
|
||||
- Consente una qualche forma di gestione differenziata tra le macchine target, ma deve
|
||||
essere gestita manualmente.
|
||||
|
||||
[[https://github.com/SuperCuber/dotter][Link alla pagina del software]][fn:22]
|
||||
[[https://github.com/SuperCuber/dotfiles][I dotfiles dello sviluppatore]][fn:23]
|
||||
|
||||
**** Pearl
|
||||
|
||||
Scritto in Python è usabile soltanto in ambito Linux/Mac.
|
||||
Approccio interessante basato sulla modularità.
|
||||
|
||||
[[https://github.com/pearl-core/pearl][Link alla pagina del software]][fn:24]
|
||||
|
||||
**** Comtrya
|
||||
|
||||
Scritto in Rust, multi-piattaforma.
|
||||
|
||||
Un progetto nato da poco che coniuga la gestione dei dotfiles con l'installazione
|
||||
del sistema da zero consentendo l'installazione anche del software.
|
||||
Nella documentazione del progetto viene definito una versione semplificata di
|
||||
Ansible o Salt.
|
||||
|
||||
Il progetto e' ancora molto giovane, ma certamente interessante.
|
||||
|
||||
[[https://github.com/comtrya/comtrya][Link alla pagina del software]][fn:25]
|
||||
|
||||
|
||||
** Una via di mezzo
|
||||
|
||||
Quello che può capitare è che magari non si ha il tempo o le conoscenze per potersi mettere
|
||||
a sviluppare un proprio modo per gestire i dotfiles e che non si trovino strumenti che ci
|
||||
piacciono.
|
||||
|
||||
Mantenendo l'intenzione di gestire in qualche modo i dotfiles non rimane che cercare in
|
||||
rete quello che più si avvicina al nostro pensiero e poi provare a modificarlo. Si può
|
||||
magari fare un lavoro di collage prendendo spezzoni e idee provenienti da più progetti.
|
||||
|
||||
Anche se utile non è necessario essere profondi conoscitori del linguaggio usato dal
|
||||
creatore originale. Certo che prima di eseguire sulla propria macchina un pezzo di codice
|
||||
preso da uno "sconosciuto" è buona regola provare almeno a capire se presenta situazioni
|
||||
in cui si possono creare dei danni.
|
||||
|
||||
Quello che si otterrà è un franken-qualcosa che magari legato con il filo di ferro fa
|
||||
quello che volevamo. Più o meno.
|
||||
|
||||
Storicamente le mie conoscenze di Bash sono sempre state piuttosto misere. Quelle di Powershell
|
||||
sono probabilmente ancora minori. Con i vecchi script ".bat" o ".cmd" di Windows si possono
|
||||
fare diverse cose ma forse questa sarebbe stata un po' troppo complessa.
|
||||
|
||||
Qualche anno fa mi sono messo alla ricerca di qualcuno che avesse risolto il mio "problema".
|
||||
Dopo vari tentativi ho trovato un qualcosa che si avvicinava alle mie esigenze, ho spudoratamente
|
||||
copiato quello che aveva fatto lui e con qualche modifica fatta cercando di limitare al massimo
|
||||
i danni mi sono avvicinato ancora di più a quello che volevo.
|
||||
|
||||
Nella realtà le mie necessità erano e sono abbastanza semplici: poter gestire i files di configurazione
|
||||
dei programmi che uso sia sulle macchine Windows che su quelle Linux.
|
||||
|
||||
Sono passati degli anni e non ho più memoria di chi è la persona da cui ho spudoratamente copiato,
|
||||
la ringrazio comunque.
|
||||
|
||||
Ad oggi ho un paio di script che, seguendo delle convenzioni nel naming dei files, mi consentono di
|
||||
gestire i miei files di configurazione partendo dallo stesso repository sia su Windows che su Linux.
|
||||
|
||||
* Conclusioni
|
||||
|
||||
Come dicevo la mia esigenza rispetto ai dotfiles è sempre stata piuttosto semplice: avere per quanto
|
||||
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.
|
||||
|
||||
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
|
||||
l'argomento è molto più trattato di quanto potessi pensare e non è considerato affatto banale come
|
||||
credevo.
|
||||
|
||||
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.
|
||||
|
||||
* Possibili approfondimenti
|
||||
|
||||
La classica ricerca su Google mostrerà la solita quantità infinita di link.
|
||||
|
||||
Ho però trovato due punti da cui partire e che, in linea di massima, concentrano quanto di più
|
||||
importante c'è da sapere. Sono due pagine che in realtà si mettono nei riferimenti l'una
|
||||
dell'altra, per questo potrei anche metterne una sola, ma per quanto alla fine contengano
|
||||
molte informazioni duplicate, si completano in quelle mancanti:
|
||||
- [[https://github.com/webpro/awesome-dotfiles][Awesome dotfiles - A curated list of dotfiles resources]][fn:26]
|
||||
- [[https://dotfiles.github.io][Your unofficial guide to dotfiles on GitHub.]][fn:27]
|
||||
|
||||
* Footnotes
|
||||
|
||||
[fn:27]https://dotfiles.github.io
|
||||
|
||||
[fn:26]https://github.com/webpro/awesome-dotfiles
|
||||
|
||||
[fn:25]https://github.com/comtrya/comtrya
|
||||
|
||||
[fn:24]https://github.com/pearl-core/pearl
|
||||
|
||||
[fn:23]https://github.com/SuperCuber/dotfiles
|
||||
|
||||
[fn:22]https://github.com/SuperCuber/dotfiles
|
||||
|
||||
[fn:21]https://github.com/deadc0de6/dotdrop
|
||||
|
||||
[fn:20]https://github.com/andsens/homeshick
|
||||
|
||||
[fn:19]https://rgoswami.me/posts/dotfiles-dotgit-bombadil
|
||||
|
||||
[fn:18]https://github.com/oknozor/dotfiles
|
||||
|
||||
[fn:17]https://github.com/oknozor/toml-bombadil
|
||||
|
||||
[fn:16]https://yadm.io
|
||||
|
||||
[fn:15]https://github.com/twpayne/dotfiles
|
||||
|
||||
[fn:14]https://github.com/twpayne/chezmoi
|
||||
|
||||
[fn:13]https://github.com/anishathalye/dotfiles
|
||||
|
||||
[fn:12]https://github.com/anishathalye/dotbot
|
||||
|
||||
[fn:11]https://www.gnu.org/software/stow
|
||||
|
||||
[fn:10]https://www.youtube.com/watch?v=aP8eggU2CaU
|
||||
|
||||
[fn:9]https://daniele.tech/2021/03/how-to-manage-dotfiles-with-a-git-bare-repository
|
||||
|
||||
[fn:8]https://www.ackama.com/blog/posts/the-best-way-to-store-your-dotfiles-a-bare-git-repository-explained
|
||||
|
||||
[fn:7]https://www.atlassian.com/git/tutorials/dotfiles
|
||||
|
||||
[fn:6]https://wiki.archlinux.org/title/XDG_Base_Directory
|
||||
|
||||
[fn:5]https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html
|
||||
|
||||
[fn:4]https://web.archive.org/web/20190202170417/https://plus.google.com/+RobPikeTheHuman/posts/R58WgWwN9jp
|
||||
|
||||
[fn:3]https://it.wikipedia.org/wiki/Dennis_Ritchie
|
||||
|
||||
[fn:2]https://it.wikipedia.org/wiki/Ken_Thompson
|
||||
|
||||
[fn:1]https://it.wikipedia.org/wiki/Rob_Pike
|
||||
Binary file not shown.
|
|
@ -0,0 +1,116 @@
|
|||
* yadm
|
||||
|
||||
Scritto in Python. Non funziona su Windows, ma non ha dipendenze aggiuntive su Linux.
|
||||
|
||||
Consente la gestione dei dotfiles in un repository con l'aggiunta dei template e anche dei dati
|
||||
crittografati (come anche chezmoi).
|
||||
|
||||
* Installazione
|
||||
|
||||
E' possibile installare il programma in vari modi (elencati nella documentazione). Un modo che
|
||||
consente l'installazione senza necessità di particolari diritti e' quello di scaricare il
|
||||
programma direttamente dal repository github:
|
||||
|
||||
#+begin_example
|
||||
mkdir ~/.local/bin
|
||||
|
||||
curl -fLo ~/.local/bin/yadm \
|
||||
https://github.com/TheLocehiliosan/yadm/raw/master/yadm \
|
||||
&& chmod a+x ~/.local/bin/yadm
|
||||
#+end_example
|
||||
|
||||
Yadm funziona come un wrapper attorno a Git con l'aggiunta di alcune particolarità specifiche per
|
||||
la gestione dei dotfiles.
|
||||
|
||||
* Partendo da zero
|
||||
|
||||
Partendo da zero la procedura prevede
|
||||
- La creazione del repository dove yadm gestirà i dotfiles
|
||||
- La sua configurazione (ricordarsi di impostare user.name e user.email)
|
||||
- La configurazione del link al repository remoto
|
||||
- L'aggiunta dei dotfiles al repository
|
||||
- Il commit
|
||||
- Il push
|
||||
|
||||
#+begin_example
|
||||
# Inizializzo il repository
|
||||
# (ricordarsi di aggiungere poi a mano user.name e user.email)
|
||||
# il repository viene creato in ~/.local/share/yadm/repo.git
|
||||
yadm init
|
||||
|
||||
# Aggiungere il server remoto
|
||||
# yadm remote add origin <url/to/remote/repo>
|
||||
|
||||
# Aggiungo vim
|
||||
yadm add .vimrc
|
||||
yadm add .vim
|
||||
yadm commit -m "Aggiunto vim"
|
||||
yadm push -u origin master
|
||||
#+end_example
|
||||
|
||||
Si possono aggiungere files o directory come se si stesse lavorando con Git
|
||||
|
||||
* Partendo con un nuova installazione, ma con repository remoto già pronto
|
||||
|
||||
Partendo da una home "vuota" ed avendo a disposizione un repository già configurato
|
||||
si procede con l'installazione del programma
|
||||
|
||||
#+begin_example
|
||||
mkdir ~/.local/bin
|
||||
|
||||
curl -fLo ~/.local/bin/yadm \
|
||||
https://github.com/TheLocehiliosan/yadm/raw/master/yadm \
|
||||
&& chmod a+x ~/.local/bin/yadm
|
||||
#+end_example
|
||||
|
||||
A questo punto si clona il repository
|
||||
|
||||
#+begin_example
|
||||
# yadm clone <url/to/remote/repo>
|
||||
yadm status
|
||||
#+end_example
|
||||
|
||||
Il comando ~clone~ cerca di fare il checkout di tutti i files presenti nel reposiotry.
|
||||
*Se un file esiste già localmente e il suo contenuto differisce da quello nel repository*
|
||||
*il file locale sarà lasciato invariato e occorrerà verificare e risolvere le differenze*.
|
||||
|
||||
* Funzionalità particolari
|
||||
|
||||
Yadm offre alcune funzionalità particolari
|
||||
|
||||
* Bootstrap
|
||||
|
||||
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,
|
||||
sarà richiamato ed eseguito con il comando
|
||||
|
||||
#+begin_example
|
||||
yadm bootstrap
|
||||
#+end_example
|
||||
|
||||
* Alternate files
|
||||
|
||||
E' possibile usare files diversi per situazioni diverse. La gestione avviene appendendo un suffisso
|
||||
al nome del file da aggiungere al repository (vedi documentazione).
|
||||
|
||||
* Templates
|
||||
|
||||
Il concetto è simile agli alternate files. I template contengono dati specifici per un host che
|
||||
saranno gestiti in input da un template processor per produrre in output il file elaborato.
|
||||
|
||||
* Encryption
|
||||
|
||||
Se vi fidate, consente la memorizzazione nel repository di informazioni crittate. 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
|
||||
comando stesso.
|
||||
|
||||
Gli hook sono gestiti con attenzione al risultato dell'esecuzione dello script. Se, ad esempio,
|
||||
uno script di "pre_commit" viene eseguito ritornando un valore diverso da zero, allora il comando
|
||||
commit non viene eseguito e il processo si ferma.
|
||||
|
||||
Loading…
Reference in New Issue