CLI-Adventskalender: dotfiles

dotfiles – die verstecken sich hinter dem elften Türchen unseres CLI-Adventskalenders.

Mit all den Änderungen und Konfigurationen die ich in den letzten Artikeln so vorgeschlagen habe, könnte eine naheliegende Frage aufkommen: Wenn ich mir meine eigene Welt baue – in der Dinge auf eine bestimmte Art und Weise funktionieren – verlerne ich dann nicht irgendwann die Shell? Und was nutzt mir all das, wenn ich regelmäßig auf unterschiedlichen Servern arbeite?

Die Antwort darauf sind …

Dotfiles

Die haben nichts mit .NET zu tun. Der Name bezieht sich auf den Punkt am Anfang des Dateinamens, der auf eine versteckte Datei hindeutet. Ein Beispiel ist die .bashrc, ein Skript, das am Anfang jeder Bash-Session ausgeführt wird. Dotfiles können systemweit gelten, sind in den meisten Fällen benutzerspezifisch (jene Dateien liegen im home-Verzeichnis des jeweiligen Nutzers) und können mit ein bißchen Tooling sogar von Verzeichnis zu Verzeichnis unterschiedlich greifen.

Wie hilft uns das jetzt beim Springen zwischen verschiedenen Systemen?

Beam uns hoch, Scotty!

Die Antwort sind git und Symlinks. Wer eine schnelle Suche auf Github nach dotfiles macht, findet zweihunderttausend Ergebnisse von Leuten, die ihre Konfigurationsdateien öffentlich ins Netz gestellt haben. Abgesehen von Angebereien und Exhibitionismus hat das den starken Vorteil, dass man von überall das Repository clonen und die eigenen Konfigurationsdateien nutzen kann. Ich habe Shortcuts, die ich vor mehr als fünf Jahren definiert habe, die ich immer noch fast jeden Tag nutze.

Man kann jetzt natürlich die Dateien an die jeweiligen Orte kopieren. Ein Symlink

ln -s /home/eric/dotfiles/vim/vimrc /home/eric/.vimrc

hat hier den Vorteil, dass man git ganz regulär weiter benutzen kann. Ein git pull holt die neuen Änderungen, ein gepushter Commit bringt den neusten Stand auf alle anderen Systeme. Natürlich ist das ständige Anlegen von potenziell einem Dutzend solcher Links recht mühselig und deshalb reden wir mal über GNU stow. Bevor wir das tun können, räumen wir unsere dotfiles auf und bringen sie in das passende Format.

├── bash
│   ├── .bash_aliases
│   └── .bashrc
└── vim
    └── .vimrc

Jetzt im dotfiles-Verzeichnis ein stow vim und alle Symlinks werden durch stow angelegt und verwaltet. Die Annahme ist hier, dass dotfiles direkt in unserem Homeverzeichnis liegt. Sonst braucht es ein

stow -t /home/eric -d /home/eric/repos/dotfiles vim

Rückgängig machen lässt sich das ganze mit einem stow -D vim.

Was gibt es denn alles?

Was kann man denn noch so alles mit dotfiles machen? Was packen andere Leute rein? Die Ideen, die ich hier gesammelt habe, sind wie die Einleitung oben schon vermuten lässt lediglich die Spitze des Eisbergs.

Shell-Konfiguration

Je nachdem welche Shell man nun einsetzen mag. Ich konzentriere mich auf Bash.

• .bashrc für Sachen, die man ausführen möchte, wenn man eine Nicht-Login-Shell aufmacht. In der Praxis heißt das „ein Terminalfenster“ vs „ssh auf einen Server“.
• .bash_aliases ist quasi wie die .bashrc, nur möchte man hier traditionell die Aliases reinlegen, um alles aufgeräumt zu halten.
• .bash_profile wird Login-Shells ausgeführt. Vielleicht schnell ein paar diagnostische Infos automatisch ausgeben? Oder eine E-Mail schicken „Jemand hat sich gerade als Du auf Deinem Server eingeloggt“?
• .bash_logout – das Gegenstück zu .bash_profile. Vielleicht soll zum Beispiel die History nicht gespeichert oder Dateien sollen aufgeräumt werden.

Desktop-Umgebung

Je nachdem welche man einsetzt (Gnome, KDE, i3, awesome, xmonad, etc), können auch hier viele interessante Shortcuts gesetzt werden. Hier ein paar Ideen:

• Fensterverhalten (übereinander, nebeneinander, gestapelt, und was passiert, wenn man einen Doppelklick auf die Titelleiste macht?)
• Schnelles Springen von Desktop zu Desktop
• Schnelles Öffnen eines Terminals oder Browsers
• Schnelles Locken, für wenn man mal nach nebenan muss
• Umschalten zwischen verschiedenen Tastaturlayouts (ich switche ungefähr hundertmal am Tag zwischen QWERTY und QWERTZ)
• Öffnen des Browsers auf bestimmten Seiten
• Viel, viel Kosmetik (alle Fenster im selben Stil, mit denselben Farben, etc)

Editor / IDE

Ob nun vim oder VSCode oder Emacs oder Intellij, alle haben sie Konfigurationsdateien, die sich leicht von System zu System übertragen lassen. Gerade für Leute wie mich, die fast jede Woche an ihrer .vimrc herumschrauben, muss ich den Nutzen nicht erklären. Für alle anderen:

• Plugins und deren Einstellungen
• Keyboard-Shortcuts
• Macros
• (für graphische IDEs) Fonts!

Terminal

• Fonts
• Farben
• Noch mehr Hotkeys

Multiplexer

Für Leute die wissen was Terminalmultiplexer (wie tmux oder screen) sind, muss ich nicht erklären, warum es gut ist, die Konfiguration mobil zu haben. Für alle anderen ist der Artikel morgen gedacht.

• Hotkeys
• Inhalte der Statusleiste
• Autostart für diverse Kommandos

Audioplayer

• Hotkeys (ihr erkennt vielleicht ein wiederkehrendes Thema)
• Playlisten, die automatisch geladen werden sollen
• Equalizer-Einstellungen

Toolleisten

• Welche Infos werden wo dargestellt?
• Was ist im Start-Menu oder Launcher?
• Hotkeys

Mail

• Hotkeys
• Fenster-Setup
• KEINE ZUGÄNGE

Filemanager

• Bevorzugter Anzeigemodus
• Einmalklicken vs Doppelklicken
• Hotkeys

RSS Reader

• Alle URLs, um die Nachrichten zu lesen, die einen interessieren
• Hotkeys
• Farben

Python / Ruby / andere REPLs

• Welche Bibliotheken sollen direkt geladen werden?
• Irgendwelche Variablen, die direkt befüllt werden sollen?
• Welche Pakete/Gems/etc sollen auf dem System vorinstalliert sein?
• Habe ich Hotkeys erwähnt?

Ein Wort der Warnung

Es ist extrem unklug, vertrauliche Dinge in ein öffentlich einsehbares Repo zu packen. Das schließt vor allem private Keys und Passwörter mit ein (selbst wenn die Systeme eigentlich nicht öffentlich erreichbar sind).

Dinge, die ich bewusst nicht aufgezählt habe, weil sie wahrscheinlich vertrauliche Informationen enthalten:

• ssh
• Browser-Profile
• git
• Gnupg

Dieser Ordner ist ein Paralleluniversum

In einer Welt mit Docker-Containern, nix-Shells und hunderten von alternativen Sandboxing-Lösungen, kann man sich schnell eine Umgebung schaffen, die sich entsprechend eines bestimmten Tasks verhält. Es muss ja nicht einmal hochspezialisierte Ultraeffizienz sein, wo p in einem Verzeichnis Python ist und im nächsten printf. Vielleicht soll einfach nur die Konfiguration auf verschiedene Dateien ausgelagert sein oder nicht jedes Mal, wenn man ein Terminal aufmacht, acht verschiedene Umgebungen hochgefahren werden.

Das einfachste Tool für diesen Job, das ich kenne, ist direnv.

Installieren und eval "$(direnv hook bash)" in die .bashrc. Dann

cd tollesprojekt
echo "export PATH=$PATH:/home/eric/tollesprojekt/bin" > .envrc
direnv allow .

Jedes Mal wenn wir mit cd in den Ordner hineingehen, wird jetzt eine Subshell mit der .envrc geladen. Die Subshell wird geschlossen, wenn wir den Ordner wieder verlassen. Je nach Ökosystem kann dies auch ein sinnvoller Ansatz für Softwareprojekte sein, in der wichtige Umgebungsvariablen (z. B. DB_URL) über eine env-Datei geladen werden.

Tausende von Tools existieren

Zum Beispiel YADM, das auch auf Git basiert und ein paar bequeme Wrapper um Verschlüsselung mitliefert. Da wir es letzten Endes nur mit Textdateien zu tun haben, lassen sich derartige Tools auch leicht selber bauen und individuell an die eigenen Bedürfnisse anpassen.