Nützliches für die .bashrc

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/</\&lt;/g' -e 's/>/\&gt;/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…

Dieser Beitrag wurde unter Technisches abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.