 "Aufmacher Artikel")
Dass das Eintippen eines Kommandos am Shell-Prompt, im X-Terminal oder in einer Konsole oft schnellere Erfolge zeitigt als eine Latte Mausklicks in einer GUI-Applikation, ist eine Binsenweisheit. Mit den Pfeiltasten lassen sich bereits eingegebene Kommandos aus der History, dem Lager für gebrauchte Kommandos, zurückholen, bearbeiten und per [Return] erneut auf die Reise schicken. Auch die [Tab]-Taste zum Ergänzen von Befehlen und Dateinamen in der bash zählt noch zur Allgemeinbildung einer Linuxerin.
The Answer Girl
Dass der Computeralltag auch unter Linux des Öfteren für Überraschungen gut ist, ist eher eine Binsenweisheit: Immer wieder funktionieren Dinge nicht oder nicht so, wie eigentlich angenommen. Das Answer-Girl im LinuxUser zeigt, wie man mit solchen Problemchen elegant fertig wird.
Doch dann hört es meistens schon auf. Spätestens, wer fünf Minuten lang mit [Pfeil hoch] und [Pfeil runter] nach einem älteren Kommando gegraben hat, das schneller neu eingetippt gewesen wäre, fragt sich, ob die Shell nicht doch noch ein paar Arbeitserleichterungen mehr bietet.
Von diesem Gedanken getrieben, entdeckte das Answer Girl in den Heften 12/2000 [1] und 04/2001 [2] den Event Designator !#, der einfach das wiederholt, was man bereits in der aktuellen Kommandozeile eingegeben hat. Mit Modifizierern wie :1 beschränkt man die Auswahl auf das zweite Wort dieses Ausdrucks (die Zählung beginnt bei Null), sodass ein
echo hallo !#:1
den Befehl echo hallo hallo ausführt. Selbst wenn man noch ein :p anhängt und das entstehende Kommando damit lediglich ausgibt ("print"), aber nicht tatsächlich ablaufen lässt, ist das eher nur nett zu wissen. Denn in der Praxis hat der/die weniger Geübte das Kommando meist komplett eingetippt, bevor er/sie sich der recht kruden Syntax erinnert.
Ausrufezeichen mit großer Wirkung
Wer jedoch dem einen oder anderen Guru schon mal beim Tippen über die Schulter geschaut hat, dem/der ist womöglich aufgefallen, dass zumindest das Ausrufezeichen recht oft über die Kommandozeile huscht, und zwar meist in der Form
!Befehlsanfang
Ein !man ruft so zum Beispiel die Manpage noch einmal auf, in der man zuletzt gestöbert hat, während !ssh den zuletzt eingegebenen ssh-Befehl erneut zur Ausführung bringt. Sie trauen der Sache nicht so recht und wollen lieber vorher wissen, welches Kommando zum Zuge käme? Dann lassen Sie uns doch einfach ausprobieren, was passiert, wenn wir den bereits erwähnten Modifizierer :p mit der Ausrufezeichensuche verknüpfen:
pjung@chekov:~$ !ssh :p ssh bashir :p pjung@bashir's password:
Das war wohl falsch: Da der Zielrechner bashir nach dem Passwort fragt, hat :p anscheinend nicht verhindert, dass das letzte ssh-Kommando, ssh bashir, ausgeführt wurde. Doch halt! Wieso steht in der ersten Antwortzeile der Shell, dass sie nun das Kommando ssh bashir :p ausführt? Da haben wir die betroffene Kommandozeile wohl schlichtweg um die Zeichenkette " :p" ergänzt. Das war zwar nicht das, was wir wollten, aber gut zu wissen, dass es geht.
[Strg-c] jedenfalls sorgt dafür, dass das fälschlich aufgerufene Kommando abgebrochen wird. Doch wo war der Fehler? Ein einfaches Leerzeichen, denn
pjung@chekov:~$ !ssh:p ssh bashir :p
zeigt tatsächlich einfach nur an, dass das zuletzt abgeschickte (aus unserem Fehlversuch herrührende) ssh-Kommando ssh bashir :p hieß. Das :p brauchen wir aber nicht. Wer jetzt nicht ohnehin entnervt ssh bashir tippt, sondern lieber ein wenig puzzelt, lässt sich mit
pjung@chekov:~$ !ssh:0-1:p ssh bashir
das Kommando anzeigen, das entsteht, wenn wir aus dem zuletzt benutzten ssh-Befehl das nullte (ssh) und das erste Wort (bashir) abgreifen.
!ssh:0-1
riefe diese Kommandozeile jetzt auf.
Einblicke in die Geschichte
Leider speichert die Bash die Ausrufezeichen-Variationen der Kommandos so nicht in ihrer History ab. Stattdessen findet man mit den Pfeiltasten oder dem Shell-Builtin (vgl. Kasten 1) history nur die bereits von der Shell ersetzte Version wieder (die history-Funktion interpretiert ein numerisches Argument als die Anzahl der aufzulistenden letzten Kommandos):
pjung@chekov:~$ history 3 955 date 956 ssh bashir :p 957 ssh bashir
Die davon ausgegebenen Kommandozeilen wiederzuverwerten, sollte anhand der Nummern kein Problem sein. Wenn sich !# auf die aktuelle Befehlszeile, !! hingegen auf die letzte bezieht, liegt es nahe, doch einfach einmal
pjung@chekov:~$ !955 date Fri Dec 21 14:45:20 CET 2001
auszuprobieren – und siehe da, es funktioniert. Der Event-Designator muss dabei nicht einmal an erster Stelle stehen: ping !956:1 etwa klaut sich einfach aus dem 956. Kommando in der History das erste Argument heraus und führt damit den Befehl ping bashir aus.
Kasten 1: Eingebaut@KL:Wenn die Anwenderin auf der Kommandozeile
drückt, beginnt die Arbeit für die Shell. Sie schaut nach, ob sie in dem, was eingetippt wurde, etwas ersetzen oder ergänzen muss (die Ausrufezeichen-Konstrukte sind ein gutes Beispiel). Erst nach dieser Vorarbeit wird sie den Kernel mit der Ausführung entsprechener Prozesse beauftragen. Beim ersten Wort der bearbeiteten Kommandozeile handelt es sich um das Kommando, das gestartet werden soll.
Die Bash und verwandte Shells schauen zunächst nach, ob es einen Alias dieses Namens gibt. Wenn nein, überprüfen sie, ob sie es mit einer Shell-Funktion zu tun haben. Das können in der Shell selbst implementierte Funktionen, die Shell-Builtins, sein oder aber auch selbst definierte. Im Gegensatz zu Aliasen können Funktionen nicht nur Argumente mit auf den Weg bekommen, sondern diese auch bearbeiten. Erst wenn die Shell weder Alias noch Funktion findet, kommt ein externes Programm zum Zuge. Das Bash-Builtin type gibt der Anwenderin die Möglichkeit, herauszufinden, ob ein Kommando tatsächlich ein eigenständiges Binary oder "nur" ein in der Shell eingebauter Befehl ist. Mit überraschenden Erkenntnissen, wie …
pjung@chekov:~$ type cd cd is a shell builtin
… die Probe auf's Exempel zeigt: Das Kommando zum Verzeichniswechseln ("change directory") ist gar keine ausführbare Datei, sondern ein Shell-Builtin, das wir mit einer selbstdefinierten Shell-Funktion überschreiben können:
pjung@chekov:~$ cd(){ echo Du willst nach $1 wechseln? Nichts gibts… ; }Wie in anderen Programmiersprachen auch folgt nach dem Funktionsnamen ein rundes Klammernpaar als Kennzeichen dafür, dass es sich um eine Funktion handelt. Allerdings kann diese Klammer bei der Bash selbst dann leer bleiben, wenn die Funktion mit (Kommandozeilen-)Argumenten hantiert.
Die geschweiften Klammern enthalten die Kommandos, die beim Funktionsaufruf auszuführen sind. Wichtig dabei: Jedes Kommando muss mit Semikolon abgeschlossen werden, und vergessen Sie das Leerzeichen nach { nicht. Mit $1 greifen wir auf das erste Kommandozeilenargument von cd zurück. Wenn wir jetzt den Wunsch zum Wechseln des Verzeichnisses verspüren, stellt sich der Rechner stur:
pjung@checkov:~$ cd /mnt/cdrom Du willst nach /mnt/cdrom wechseln? Nichts gibts…
Zum Vergleich: Mit einem cd-Alias ist die Auswertung der Parametervariablen 1 nicht möglich:
pjung@chekov:~$ alias cd="echo Du willst nach $1 wechseln? Nichts gibts…" pjung@chekov:~$ cd /tmp Du willst nach wechseln? Nichts gibts… /tmp
Hierbei nimmt die Shell den gesamten "cd /tmp"-Befehl und tut nichts anderes, als cd mit echo Du willst nach $1 wechseln? Nichts gibts... zu ersetzen. Ausgeführt wird echo Du willst nach $1 wechseln? Nichts gibts... /tmp. Mit unalias cd heben wir den Alias wieder auf. Wenn wir jetzt das cd-Kommando eingeben, greift die Shell wieder auf die von uns definierte Funktion zurück. Um die loszuwerden und wieder mit dem Builtin ordentlich das Verzeichnis wechseln zu können, gibt es glücklicherweise ein weiteres Builtin namens unset: unset cd macht dem Spuk einer renitenten Shell ein Ende.
Einem Freund empfehlen
