Im Laufe der Jahre habe ich einige nützliche Dinge angesammelt, die ich in jede .bashrc
übernehme, wenn ich auf einem Computer mehr als nur gelegentlich arbeite.
Einige davon sind vielleicht auch für andere Menschen von Nutzen.
(Wer es nicht sofort bemerkt: Nein, das hier ist kein Tutorial, wie man die Shell bedient. Es gibt nur sehr knappe Erläuterungen.)
Standardausgabe in das Clipboard kopieren
Hierfür muss xsel
installiert sein. Die meisten »modernen« Linux-Distributionen installieren die alten Kommandozeilen-Tools für XWindows nicht mehr standardmäßig, so dass man es gegebenenfalls nachinstallieren muss.
Mit xsel
könnte man sogar schon auskommen, aber als tippfauler Mensch mache ich meine eigene Funktion, die einerseits die Ausgabe auf die Konsole ausgibt, damit ich sie direkt lesen kann, und die sie andererseits in das Clipboard kopiert:
clip() { cat "$@" | tee /dev/tty | xsel -bi }
Beispiel: ls -l | clip
gibt das Verzeichnislisting aus und kopiert es gleichzeitig in die Zwischenablage.
HTML-Entitäten
Es kommt bei mir erstaunlich häufig vor, dass ich Texte auf die eben beschriebene Weise in die Zwischenablage kopiere, die ich anschließend in ein HTML-Dokument einfüge. Wenn dabei nur ein bis drei reservierte Zeichen von Hand durch die jeweilige Entität ersetzt werden müssen, geht das ja noch, obwohl ich es immer wieder einmal vergesse. Besser ist es für mich, dafür eine Funktion in der Shell zu haben:
htmlentities () { sed -e 's/&/\&/g' -e 's/"/\"/g' \ -e 's/</\</g' -e 's/>/\>/g' "$@" }
Beispiel: Vermutlich kann sich jeder vorstellen, wie sehr es hirnt, so eine Zeile in HTML zu tippen. Gut, dass ich diese Funktion schon fertig in meiner .bashrc
hatte, so dass ich sie folgendermaßen in die Zwischenablage bekam, um sie direkt in das Editorfenster einfügen zu können, in dem ich diesen Text schreibe:
$ sed -n '/^htmlentities/,/}/p' .bashrc | htmlentities | clip
🙂
Wer nicht sofort versteht, wie ich mit sed
die Funktionsdefiniton aus der .bashrc
extrahiert habe: Dieses olle Programm sed
ist unendlich praktisch und kann einem leicht viel Arbeit sparen. Meiner Meinung nach sollte jeder Mensch, der öfter an einem Computer mit einem unixoiden Betriebssystem arbeitet, damit ein bisschen umgehen können. Leider ist die man-page (auf GNU-Systemen) sehr kurz angebunden und überhaupt nicht hilfreich. Wer gewohnheitsmäßig mit dem hervorragend dokumentierten vim
editiert, hat es dafür aber leicht, sed
zu erlernen, weil es der vim
-Befehlszeile sehr ähnlich ist.
Besserer Prompt
Die eben angegebenen Funktionen werden auch mit anderen Shells funktionieren, insbesondere mit der ksh
¹. Das gilt nicht für diesen Tipp, er geht in dieser Form nur mit der bash
.
Grundsätzlich finde ich es ja gut, wenn mein aktuelles Verzeichnis im Prompt angezeigt wird – aber da ich sehr häufig tief verschachtelte Unterverzeichnisse mit zum Teil sehr langen Namen habe, ist es beim Arbeiten für mich eher verwirrend, dass mir der gesamte Pfad angezeigt wird. Wenn ich den genauen Pfad des Verzeichnisses wissen möchte, in dem ich mich befinde, kann ich immer noch pwd
tippen. Deshalb schreibe ich in meine .bashrc
immer folgendes:
export PS1='\u@\h [\W] \$ '
Das führt zu einer in meinen Augen wesentlich angenehmeren Darstellung des aktuellen Arbeitsverzeichnisses im Prompt:
elias@porz [~] $ pwd /home/elias elias@porz [~] $ cd /usr/local/share/games/mame/roms/ elias@porz [roms] $ du -hs . 42G . elias@porz [roms] $ pwd /usr/local/share/games/mame/roms elias@porz [roms] $ cd elias@porz [~] $ _
Die Darstellung des Verzeichnisses in eckigen Klammern ist nur mein schlechter Geschmack, hier kann jeder machen, was er will. Zum Beispiel eine farbige Ausgabe mit ANSI-Sequenzen (finde ich persönlich schrecklich).
Wer nicht häufiger in ssh
-Sitzungen auf anderen Rechnern arbeitet, kann natürlich die Angabe \u@\h
weglassen, weil ja immer klar ist, an welchem Rechner man arbeitet. Ich hingegen würde neben dem bekannten who am i
auch ein where am i
benötigen… und die Verpeiltheit kommt manchmal dazu…
¹Weil die ksh
die eigentlich POSIX-konforme Shell ist, die bash
des GNU-Projektes hingegen in einigen Dingen (insbesondere in der Behandlung von Pipes in Kontrollstrukturen) inkompatible Wege geht, versuche ich immer ein bisschen an die ksh
zu denken. Vielleicht muss ich einige meiner Skripten ja mal auf einem richtigen Unix laufen lassen…