Dieser Test ist analot zum Vorigen. Nur wird hier geprüft ob eine Datei älter ist als die andere

#!/bin/sh

#
# prüfen ob die Datei welche von zwei Dateien älter ist
# ot steht für older than
#

touch testdatei_1
sleep 2
touch testdatei_2

if [[ testdatei_2 -ot testdatei_1 ]] ; then
    echo "das hätte nicht passieren dürfen."
    echo "Die testdatei_2 darf nicht älter "\
         "sein als testdatei_1."
else
    echo "so ist es richtig, die testdatei_1 ist älter als testdatei_2"
fi

if [[ testdatei_1 -ot testdatei_2 ]] ; then
    echo "so ist es richtig, die testdatei_1 ist älter als testdatei_2"
else
    echo "das hätte nicht passieren dürfen."
    echo "Die testdatei_2 darf nicht älter "\
         "sein als testdatei_1."
fi

Vergleiche von Zeichenketten

Prüfen ob eine Zeichenkette einem Muster gleicht

In diesem Beispiel werden zwei Zeichenketten miteinander verglichen. Im ersten Durchgang sind sie ungleich, damit das bisherige Schema eingehalten wird. Im Zweiten Durchgang wird eine wahre Aussage in der if-Klausel erzeugt. Und so wird dann auch wieder die erste Alternative ausgeführt. Das =-Zeichen wird hier als Vergleichsoperator eingesetzt.

#!/bin/sh

#
# prüfen ob eine Zeichenkette einem Muster gleicht
#

str1="Das Restaurant am Ende des Universums"
str2="Machts gut und danke für den Fisch"

if [[ $str1 = $str2 ]] ; then
    echo "das hätte nicht passieren dürfen."
    echo "die beiden Zeichenketten sind doch ungleich."
else
    echo "Das paßt. Die Zeichenketten sind ungleich"
fi

str2="Das Restaurant am Ende des Universums"

if [[ $str1 = $str2 ]] ; then
    echo "Das paßt. Die Zeichenketten sind gleich"
else
    echo "das hätte nicht passieren dürfen."
    echo "die beiden Zeichenketten sind doch gleich."
fi

Prüfen ob eine Zeichenkette sich vom Muster unterscheidet

Dieses Beispiel ist völlig analog zum vorigen. Nur die Zeichenketten sind anders gesetzt und der Vergleichsoperator ist diesmal die Zeichenkombination !=. Diese Zeichenkombination ergibt sich daraus, daß das Ausrufezeichen ! bei vielen Programmiersprachen mit der Bedeutung NOT befrachtet ist. Es negiert also die darauffolgende Aussage. Da die Aussage $str1 = $str2 wahr wäre, wird sie durch den logischen Operator ! zu einer falsche Aussage.

#!/bin/sh


#
# prüfen ob eine Zeichenkette sich vom Muster unterscheidet
#

str1="Das Restaurant am Ende des Universums"
str2="Das Restaurant am Ende des Universums"

if [[ $str1 != $str2 ]] ; then
    echo "das hätte nicht passieren dürfen."
    echo "die beiden Zeichenketten sind doch gleich."
else
    echo "Das paßt. Die Zeichenketten sind gleich"
fi

str2="Machts gut und danke für den Fisch"

if [[ $str1 != $str2 ]] ; then
    echo "Das paßt. Die Zeichenketten sind ungleich"
else
    echo "das hätte nicht passieren dürfen."
    echo "die beiden Zeichenketten sind doch ungleich."
fi

Prüfen ob eine Zeichenkette "kleiner" ist als eine andere

Dieses Beispiel zeigt wie zwei Zeichenketten darauf verglichen werden ob eine kleiner ist. Dies mutet zunächst etwas komisch an. Tatsächlich wird nicht verglichen ob eine Zeichenkette länger ist als die andere sondern es werden Position für Position die jeweiligen Zeichen in diesen Zeichenketten numerisch verglichen. Ein Zeichen wird im Computer ja nur als Zeichen interpretiert. Intern wird es als Zahl behandelt. Für die korrekte Umsetzung von Zahl zu Zeichen werden Tabellen verwendet. Die ASCII-Tabelle ist so eine. Für Shell-Scripte ist dies auch die weitaus am häufigsten benutzte Tabelle. Im ersten Durchgang sind die beiden Zeichenketten absolut gleich. Im zweiten Durchgang wurde in str1 ein kleines 'a' durch ein großes 'A' ersetzt. Das reicht, der Vergleichsoperator < sieht einen unterschied und liefert eine wahre Aussage.

#!/bin/sh


#
# prüfen ob eine Zeichenkette kleiner ist als die andere
#

str1="Das Restaurant am Ende des Universums"
str2="Das Restaurant am Ende des Universums"

if [[ $str1 < $str2 ]] ; then
    echo "das hätte nicht passieren dürfen."
    echo "die beiden Zeichenketten sind doch gleich."
else
    echo "Das paßt. Die Zeichenketten sind gleich"
fi

str1="Das Restaurant Am Ende des Universums"

if [[ $str1 < $str2 ]] ; then
    echo "Das paßt. Die erste Zeichenkette ist \"kleiner\""
else
    echo "das hätte nicht passieren dürfen."
    echo "die beiden Zeichenketten sind doch ungleich."
fi

Prüfen ob eine Zeichenkette "größer" ist als eine andere

Dieses Beispiel ist analog zum vorigen. Nur der Vergleichsoperator ist umgekehrt.

#!/bin/sh

#
# prüfen ob eine Zeichenkette größer ist als die andere
#

str1="Das Restaurant am Ende des Universums"
str2="Das Restaurant am Ende des Universums"

if [[ $str1 > $str2 ]] ; then
    echo "das hätte nicht passieren dürfen."
    echo "die beiden Zeichenketten sind doch gleich."
else
    echo "Das paßt. Die Zeichenketten sind gleich"
fi

str2="Das Restaurant Am Ende des Universums"

if [[ $str1 > $str2 ]] ; then
    echo "Das paßt. Die erste Zeichenkette ist \"größer\""
else
    echo "das hätte nicht passieren dürfen."
    echo "Die beiden Zeichenketten sind doch ungleich."
fi

Prüfen ob eine Zeichenkette nicht leer ist

Dieses Beispiel zeigt wie man überprüft ob in einer Zeichen-Variablen ein Wert gespeichert ist. Wenn nichts gespeichert ist, dann liefert dieser Vergleich eine falsche Aussage. Der Vergleichsoperator orientiert sich an der Länge der Zeichenkette. Wenn nichts gespeichert ist, dann ist die Länge der Zeichenkette Null (0).

#!/bin/sh


#
# prüfen ob eine Zeichenkette größer ist als die andere
#

str1=""

if [[ -n $str1 ]] ; then
    echo "das hätte nicht passieren dürfen."
    echo "die Zeichenkette ist doch leer"
else
    echo "Das paßt. Die Zeichenkette ist leer"
fi

str1="Das Restaurant am Ende des Universums"

if [[ -n $str1 ]] ; then
    echo "Das paßt. Die Zeichenkette hat jetzt einen Inhalt"
else
    echo "das hätte nicht passieren dürfen."
    echo "Die Zeichenketten hat doch einen Inhalt"
fi

Prüfen ob eine Zeichenkette leer ist

Dieses Beispiel ist analog zu dem vorigen Beispiel. Mit -z wird diesmal nur getestet ob die Zeichenkette leer ist. -z liefert bei einer leeren Zeichenkette eine wahre Aussage.

#!/bin/sh

#
# prüfen ob eine Zeichenkette größer ist als die andere
#

str1="Das Restaurant am Ende des Universums"

if [[ -z $str1 ]] ; then
    echo "das hätte nicht passieren dürfen."
    echo "die Zeichenkette ist doch nicht leer"
else
    echo "Das paßt. Die Zeichenkette ist nicht leer"
fi

str1=""

if [[ -z $str1 ]] ; then
    echo "Das paßt. Die Zeichenkette ist jetzt leer"
else
    echo "das hätte nicht passieren dürfen."
    echo "Die Zeichenketten ist doch leer"
fi

Vergleiche von Zahlen

Vergleich ob eine Zahl kleiner ist als eine andere

In diesem Beispiel werden also zwei Zahlen miteinander verglichen. Operator, der vergleicht ob die linke Zahl kleiner ist als die rechte heißt -lt und bedeutet less than. Ansonsten ist alles wie in den vorigen Beispielen. Wenn die Aussage wahr ist, dann wird die erste Alternative ausgeführt sonst wird die zweite Alternative ausgeführt.

#!/bin/sh

#
# prüfen ob eine Zahl kleiner ist als eine andere Zahl
#

let z1=5
let z2=3

if [[ $z1 -lt $z2 ]] ; then
    echo "Das hätte nicht passieren dürfen."
    echo "z1 ist doch größer als z2."
else
    echo "Das paßt. z1 ist größer als z2."
fi

let z2=7

if [[ $z1 -lt $z2 ]] ; then
    echo "Das paßt. z1 ist kleiner als z2."
else
    echo "Das hätte nicht passieren dürfen."
    echo "z1 ist doch kleiner als z2."
fi

Vergleich ob eine Zahl kleiner oder gleiche ist als eine andere

Auch in diesem Beispiel werden zwei Zahlen miteinander verglichen. Diesmal lautet der Vergleich -lt und bedeutet less or equal. Dieses Beispiel besteht aus drei Abschnitten, weil die if-Klausel unter zwei Bedingungen eine wahre Aussage liefert. Hier ist also ausdrücklich ein Beisplei für den Fall, daß z1 kleiner also z2 ist und eines für den Fall, daß z1 gleich z2 ist.

#!/bin/sh

#
# prüfen ob eine Zahl kleiner oder gleich ist als eine andere Zahl
#

let z1=5
let z2=3

if [[ $z1 -le $z2 ]] ; then
    echo "Das hätte nicht passieren dürfen."
    echo "z1 ist doch größer als z2."
else
    echo "Das paßt. z1 ist größer als z2."
fi

let z2=5

if [[ $z1 -le $z2 ]] ; then
    echo "Das paßt. z1 ist gleich z2."
else
    echo "Das hätte nicht passieren dürfen."
    echo "z1 ist doch gleich z2."
fi

let z2=7

if [[ $z1 -le $z2 ]] ; then
    echo "Das paßt. z1 ist kleiner als z2."
else
    echo "Das hätte nicht passieren dürfen."
    echo "z1 ist doch kleiner als z2."
fi

Vergleich ob zwei Zahlen gleich sind

Das folgende Beispiel entspricht weitgehend dem Vorangegangenen. Der Vergleichsoperator ist jetzt -eq und bedeutet equal.

#!/bin/sh


#
# prüfen ob eine Zahl gleich einer anderen Zahl ist
#

let z1=5
let z2=3

if [[ $z1 -eq $z2 ]] ; then
    echo "Das hätte nicht passieren dürfen."
    echo "z1 ist doch größer als z2."
else
    echo "Das paßt. z1 ist größer als z2."
fi

let z2=5

if [[ $z1 -eq $z2 ]] ; then
    echo "Das paßt. z1 ist gleich z2."
else
    echo "Das hätte nicht passieren dürfen."
    echo "z1 ist doch gleich z2."
fi

Vergleich ob eine Zahl größer oder gleich ist als eine andere

Das folgende Beispiel entspricht weitgehend dem Vorangegangenen. Der Vergleichsoperator ist jetzt -ge und bedeutet greater or equal. Weil die if-Klausel wieder unter zwei verschiedenen Voraussetzungen eine wahre Aussage liefert besteht dieses Beispiel auch wieder aus drei Abschnitten.

#!/bin/sh

#
# prüfen ob eine Zahl größer oder gleich einer anderen Zahl ist
#

let z1=3
let z2=5

if [[ $z1 -ge $z2 ]] ; then
    echo "Das hätte nicht passieren dürfen."
    echo "z1 ist doch kleiner als z2."
else
    echo "Das paßt. z1 ist kleiner als z2."
fi

let z1=5

if [[ $z1 -ge $z2 ]] ; then
    echo "Das paßt. z1 ist gleich z2."
else
    echo "Das hätte nicht passieren dürfen."
    echo "z1 ist doch gleich z2."
fi

let z2=3

if [[ $z1 -ge $z2 ]] ; then
    echo "Das paßt. z1 ist größer z2."
else
    echo "Das hätte nicht passieren dürfen."
    echo "z1 ist doch größer als z2."
fi

Vergleich ob eine Zahl größer ist als eine andere

Dieses Beispiel besteht ausnahmsweise mal aus drei Abschnitte. Ist aber ansonsten analog zu den vorangegangenen. Es zeigt, daß der Vergleichsoperator -gt eben auch bei Gleichheit eine falsche Aussage liefert. Das ist ja auch beabsichtigt.-gt steht für greater than.

#!/bin/sh

#
# prüfen ob eine Zahl größer als eine andere Zahl ist
#

let z1=3
let z2=5

if [[ $z1 -gt $z2 ]] ; then
    echo "Das hätte nicht passieren dürfen."
    echo "z1 ist doch kleiner als z2."
else
    echo "Das paßt. z1 ist kleiner als z2."
fi

let z1=5

if [[ $z1 -gt $z2 ]] ; then
    echo "Das hätte nicht passieren dürfen."
    echo "z1 ist doch gleich z2."
else
    echo "Das paßt. z1 ist gleich z2."
fi

let z2=3

if [[ $z1 -gt $z2 ]] ; then
    echo "Das paßt. z1 ist größer z2."
else
    echo "Das hätte nicht passieren dürfen."
    echo "z1 ist doch größer als z2."
fi

Vergleich ob zwei Zahlen ungleich sind

Und dieses ist das letzte Beispiel. Es zeigt wie man zwei Zahlen auf Ungleichheit prüft. Hierzu wird der Operator -ne verwendet. -ne bedeutet -not equal.

#!/bin/sh

#
# prüfen ob eine Zahl ungleich einer anderen Zahl ist
#

let z1=5
let z2=5

if [[ $z1 -ne $z2 ]] ; then
    echo "Das hätte nicht passieren dürfen."
    echo "z1 ist doch gleich z2."
else
    echo "Das paßt. z1 ist gleich z2."
fi

let z2=3

if [[ $z1 -gt $z2 ]] ; then
    echo "Das paßt. z1 ist ungleich z2."
else
    echo "Das hätte nicht passieren dürfen."
    echo "z1 ist doch ungleich z2."
fi

Ich selbst habe es schon mehrmals erlebt, daß jemand sinngemäß nach dem Motto gehandelt hat: "Das erkläre ich nicht, daß ist doch trivial!". Mit dem Ergebnis, daß viele aus der Vorlesung zwar diese Haltung übernehmen aber das eigentliche Thema nicht verstanden haben. Wenn schon was so trivial ist, daß man es nicht behandeln muß, dann muß man die Kursteilnehmer am Ende mit solchen Trivialitäten auch gnadenlos rausprüfen. Genau das geschieht aber nicht. Daher verfolge ich hier eine andere Vorgehensweise, auch wenn's länglich wird. Sie dürfen sich also jetzt schon auf die nächste Abhandlung freuen. Und wem das noch nicht reicht, dem sei das Buch "A suitable boy" von Vikram Seth empfohlen.

Wer sich jetzt schon gefreut hat, daß die Fallunterscheidungen mit if hier ein Ende gefunden hätten, der hat sich leider zu früh gefreut. Nach diesen vielen unterschiedlichen Vergleichsoperationen sind jetzt noch Aussagen mit implizitem Aufruf von Kommandos fällig.

Auswerten der Returnwerte von Kommandos

Auswerten eines einfachen Kommandos

Man kann auch ganz einfach eine Fallunterscheidung mit dem Erfolg oder Miserfolg eines Shell-Kommandos b.z.w. eines Programms verbinden. Wie im Nachfolgenden Beispiel reicht es das Programm einfach ohne eckige Klammern in die Aussage der if-Klausel zu stellen. Vorsicht ist jedoch bei Programmen geboten, die Ausgaben produzieren. Im Zweiten Abschnitt dieses Beispiels sehen Sie, daß die Ausgabe von einem grep-Kommando nach /dev/null umgeleitet wird. Auf diese Weise wird die Ausgabe unterdrückt.

#!/bin/sh

#
# auswerten des Rückgabewertes eines Kommandos
# erst mal einfach
#

suchname="billgates"
suchdatei="/etc/passwd"

if grep $suchname $suchdatei ; then
    echo "o mei, den lösch ich sofort"
else
    echo "hier geht noch alles mit rechten Dingen zu"
fi

suchname="daemon"

if grep $suchname $suchdatei > /dev/null ; then
    echo "schrecklich, geistert es jetzt auf meinem Rechner?"
else
    echo "Schlimmer noch. Die Kiste ist von allen guten Geistern verlassen."
fi

Auswerten verketteter Kommandos

In diesem Beispiel werden mehrere Kommandos miteinander verknüpft, indem die Ausgabe des einen in die Eingabe des nächsten umgeleitet wird. Damit das für die if-Klausel wie ein Kommando aussieht, wird es in Hochkomma gestellt. Aber nicht irgendwelche Hochkomma. Bitte beachten Sie genau welche Sie verwenden. Auf der Deutschen Tastatur finden Sie diese Zeichen auf der zweiten Belegung (SHIFT) auf der Taste zwischen dem scharfen S(ß) und der -Taste (sagt mir mal jemand wie das Ding auf deutsch heißt)

#!/bin/sh

#
# und jetzt mit mehreren Kommandos in einer Reihe
#

os_type=`uname -s`

if `echo $os_type | grep 'Irix' > /dev/null`; then
    echo "Das hätte nicht passieren sollen"
else
    echo "Paßt, ist ja auch nur Linux"
fi

if `echo $os_type | grep 'Linux' > /dev/null`; then
    echo "Paßt, HP-UX wäre mir aber lieber"
else
    echo "Das hätte nicht passieren sollen."
fi

In diesem Beispiel wird zunächst nachgesehen ob der Benutzer "hugo" in der Datei /etc/passwd eingetragen ist. Falls ja liefert diese Teilaussage schon mal ein wahres Ergebnis. Die Zeichenkette, die diese Operation liefert wird in der Variablen zeile gespeichert. Der Inhalt von zeile wird dann mit cut -d ":" -f 4 weiterverarbeitet. Das Ergebnis dieser Aussage ist immer wahr. Die Ausgabe von cut wird wieder in der Variablen zeile gespeichert. cut teilt in diesem Prozeßschritt die Zeile aus /etc/passwd in einzelne Spalten ein. Diese Spalten sind durch das Colon(:) getrennt. Ein Zeichen, das diese Trennfunktion erfüllt, nennt man Delimiter. Von den so eingeteilten Spalten nimmt cut die vierte und gibt deren Inhalt aus. Im letzten Schritt wird die Ausgabe von cut, die jetzt in der Variablen zeile gespeichert ist nach der Zeichenkette "20" durchsucht. Diese drei Prozeßschritte sind gleichzeitig Teilaussagen der if-Klausel. Die Rückgabewerte ( return-values) der einzelnen Schritte werden als Aussagen mit dem &&-Operator verknüpft. Nur wenn alle wahr sind, ist die gesamte Aussage wahr. Wenn eine einzige falsch ist, dann ist die gesamte Aussage falsch. Das ist das Wesen einer &&-Verknüpfung. Anders sieht's natürlich aus, wenn Teilaussagen mit || (ODER) verknüpft werden.

Damit nicht alles in eine Zeile geschrieben werden muß wird in diesem Beispiel die if-Klausel mit dem backslash (\) umgebrochen. Ich selbst bevorzute es wenn die UND- und ODER-Operatoren schön in Reih und Glied unter dem if-Schlüsselwort stehen. Man sucht nicht lange wie die Verknüpfung aufgebaut ist. Wenn dagegen alles gut gemischt ist, dann kann man leicht was übersehen.

#!/bin/sh

if zeile=`grep hugo /etc/passwd` \
&& zeile=`echo $zeile | cut -d ":" -f 4` \
&& `echo $zeile | grep 20 > /dev/null 2>&1` ; then
    echo "hallo"
else
    echo "ollah"
fi

Fallunterscheidungen mit case

Fallunterscheidungen mit case bieten eine Einfache Möglichkeit zwischen vielen Alternativen zu unterscheiden. Sie sind einfach strukturiert und daher leicht lesbar. Ihr wesentlicher Nachteil ist, daß sie keine komplexen Ausdrücke wie die if-Konstruktion zulassen. Glücklicherweise wird die aber gar nicht so oft benötigt. Und so hat jede der beiden Strukturanweisungen ihren Platz und keine hat ihn zu Unrecht. Die beiden sind genau so gemacht wie sie gebraucht werden. Für die meisten Programmierer ist das nur eine Frage der Übung.

Wie immer gibt es jedoch ein paar Kleinigkeiten, die sind keine Frage der übung sondern eine Frage der Sorgfalt. Eine dieser Kleinigkeiten ist die äußere Form und im Zusammenhang mit Fallunterscheidungen ist es auch immer die Frage was geschen soll, wenn die gestellte Bedingung nicht erfüllt ist. Bei if Statements ist das die Frage nach dem dangling else und bei case Statemente ist das die Frage nach dem Default. Strenge Programmiersprachen zwingen den Programmierer an dieser Stelle vollständigen Code zu schreiben. Sprachen wie Shell-Script oder C tun dies nicht. Dadurch sind es noch lange keine schlechten Programmiersprachen. Es gibt keine schlechten Programmiersprachen. Es gibt nur die falsche Auswahl der Programmiersprache und es gibt schlampige und schlechte Programmierer.

Die Syntax von case sieht so aus:

case Ausdruck in
    Muster1 )
        Befehle
        ;;
    Muster2 )
        Befehle
        ;;
    Wildcard )
        Befehle
        ;;
esac

Beispiel-Script zu Fallunterscheidungen mit case

Bei dem folgenden Beispiel muß die sog. Locality beachtet werden. Diese kann mit der Umgebungsvariablen LANG gesetzt b. z. w. abgefragt werden. Auf dem System, auf dem ich diese Beispiele entwickelt habe war die LANG-Variable auf den Wert en_US gesetzt. Das führt dazu, das dieses Beispiel auf Rechnern, bei denen diese Variable einen anderen Wert hat nicht funktionieren würde. Daher wird die LANG-Variable explizit gesetzt.

#!/bin/sh

LANG=en_US

case `date +%a` in
    Mon) echo "Montag"
         ;;
    Tue) echo "Dienstag"
         ;;
    Wed) echo "Mittwoch"
         ;;
    Thu) echo "Donnerstag"
         ;;
    Fri) echo "Freitag"
         ;;
    Sat) echo "Samstag"
         ;;
    Sun) echo "Sonntag"
         ;;
    *) echo "Fehler"
       exit 1
esac

exit

Das war auch schon alles, was man zu der Fallunterscheidung mit case sagen kann. Anstelle der echo Statements können freilich auch kompliziertere Befehlsfolgen stehen. Und anstelle von `date +%a` könnte auch eine Variable oder ein beliebiger anderer Ausdruck ausgewertet werden.

Iterationen

Iterationen dienen dazu, einen Abfolge von Verarbeitungsschritten so lange zu wiederholen, bis eine bestimmte Bedingung erfüllt ist. Diese Wiederholungen nennt man auch Schleifen. Im täglichen Leben führen wir diese Schleifen ständig aus.

Beispiel:
Schneide solange Scheiben vom Brotlaib ab, bis Du sechs scheiben hast. Oder
Spühle solange schmutzige Teller, bis keine schmutzigen Teller mehr da sind.

Iterationen als Mengenoperation

Die beiden Beispiele zeigen bereits einen wichtigen Unterschied. Die eine ist eine Zählschleife und die andere prüft ob eine Abbruchbedingung erfüllt ist. Beide unterscheiden sich also äußerlich. Formal unterscheiden sie sich nicht, da beide genau genommen eine Bedingung prüfen. Die erste prüft ob ein Zähler einen bestimmten Wert erreicht hat. In sogenannten 3GL Sprachen werden solche Zählschleifen eher häufig programmiert. In Shell-Scripten erscheinen Zählschleifen viel häufiger als reine Mengenoperation.

Beispiel:

#!/bin/sh

for i in 1 2 3 4 5 6 7 8 9; do
    man -S$i stat
done

Auf den ersten Blick erscheint diese Schleife als würde sie von eins bis neun durchzählen. Dies trifft aber nicht zu. Vielmehr geben wir der Iteration eine Menge mit den Elementen .

Anmerkung:
Das Kommando man ist nicht auf allen Systemen gleich implementiert. Die Option "-S" für die Auswahl der Section kommt so auf Linux-Systemen vor. Auf FreeBSD gibt man nur die Nummer für die Section an. Gegebenenfalls muß man einfach die man-page zu man durchlesen.

Iterationen als Zählschleife

Beispiel:

#!/bin/sh

let i=1

while [[ i -lt 10 ]]; do
   man -S$i stat
   let i=i+1
done

Eine andere Möglichkeit, das hinzuschreiben ist zeigt das folgende Beispiel:

#!/bin/sh

let i=1

while (( i < 10 )); do
   man -S$i stat
   let i=i+1
done

Im Grunde prüfen alle Schleifen ob eine Bedingung wahr ist. Dies tritt je nach Konstruktion der Schleife mehr oder weniger deutlich in Erscheinung.

Iterationen mit Wahrheitsprüfung als Abbruchbedingung

Eine Schleife mit Wahrheitsprüfung benötigen wir, wenn es nichts zu zählen gibt. Dies kann z. B. der Fall sein, wenn wir aus einer Datei lesen wollen. Hier gibt's aber zunächst ein einfaches Beispiel für eine while-Schleife mit einer Abbruchbedingung die so gestrickt ist:

#!/bin/sh

stop=false

while [[ $stop != true ]]; do
   read -p "enter \"true\" to stop: " stop
   echo $stop
done

Solange man irgend etwas anderes als true eingibt läuft die Schleife immer weiter. Sobald man das Wort true eingibt, wird die Schleife beendet und das Program hört auf zu "arbeiten".

Parameter und Argumentenlisten

Es ist immer ganz praktisch, wenn wir einem Script beim Aufruf ein paar Parameter mitgeben können. Mal ist es nur einer, mal eine ganze Liste. Nachfolgend sehen wir ein paar Möglichkeiten, diese Parameter zu verarbeiten:

Einfache Argumentenlisten

Beim Aufruf eines jeden Programs wird ein Array angelegt in dem alle Parameter, die mit der Kommandozeile übergeben wurden, gespeichert sind. Genauso wie bei C-Programmen liegt der eigentliche Programmname in ersten Feld. Und wie das in der Informatik halt so ist fangen wir mit dem Zählen bei Null (0) an. Wenn man also alle Einträge in der Argumentenliste indiziert, dann ist der mit der Nummer 0 der erste Eintrag. So ist das eben.

#!/bin/sh

echo "\$0="$0
echo "\$1="$1
echo "\$2="$2
echo "\$3="$3

Und das Ergebnis sieht dann so aus:

# sh alist.sh bla blub hallo
$0=alist.sh
$1=bla
$2=blub
$3=hallo
#

Variable Argumentenlisten

Was tun, wenn man nicht weiß, wieviel Parameter mit dem Kommandozeilenaufruf mitgeliefert werden? Irgendwie muß man mit dieser Ungewißheit ja fertig werden. Das folgende Beispiel zeigt, wie das funktionieren könnte:

#!/bin/sh

let var_cnt=1

weiter=true

while [[ $weiter = true ]]; do
    argv=\$$var_cnt
    wert=`eval echo $argv`
    if [[ -z $wert ]]; then
        weiter=false
    else
        echo "-->"$wert
    fi
    let var_cnt=$var_cnt+1
done

In diesem Beispiel werden die Variablen von $1 bis $<n> durgezählt, wie das im Abschnitt Vektoren und Felder (Arrays) vorgestellt wurde.

Variable Argumentenlisten mit getopts

Mit dem UNIX-Betriebssystem ist eine ganz bestimmte Syntax für die Übergabe von Kommandzeilenparametern eingeführt. Ich sag' einfach mal, daß das mit dem UNIX-Betriebssystem gekommen ist. Auch wenn die Gefahr besteht, daß mich jemand verbessert und sagt, es wäre immerhin schon mit MULTIX eingeführt worden. Die Syntax ist dabei recht flexibel und einfach.

Einzelne Parameter werden mit einem Präfix übergeben. Dieser Präfix besteht aus einem Minus-Zeichen "-" und einem charakteristischen Buchstaben. Diesem Buchstaben wird dann der Parameter zugeordnet. Der Systemaufruf getopts liefert dann einen Parameter nach dem anderen.

Die Parameterverarbeitung mit getopts erlaubt die Parameterübergabe flexibel zu gestalten. So ist es nicht notwendig immer alle Parameter mitzugeben. Wenn einer Fehlt, wird er von getopts einfach nicht verarbeitet.

Beispiel:

#!/bin/sh

while getopts s:g:b: value; do
    echo "value = " $value
    echo "optarg =" $OPTARG
    case $value in
    s)    rflag=1
          surname="$OPTARG"
          ;;
    g)    wflag=1
          given_name="$OPTARG"
          ;;
    b)    sflag=1
          dt_of_birth="$OPTARG"
          ;;
    ?)    printf "\n\nUsage: %s: -s  -g  -v \n\n" $0
          exit 1
          ;;
    esac
done

echo "surname       = " $surname
echo "given name    = " $given_name
echo "date of birth = " $dt_of_birth

Der Aufruf des Programms führt dann zum folgenden Ergebnis:

# sh gtopt.sh -s Huber -g Hugo -b 05.07.1988
value =  s
optarg = Huber
value =  g
optarg = Hugo
value =  b
optarg = 05.07.1988
surname       =  Huber
given name    =  Hugo
date of birth =  05.07.1988

Wenn man's aber falsch aufruft, dann erhält man auch ein unerwünschtes Ergebnis:

# sh gtopt.sh -s Huber Maier -g Hugo -b 05.07.1988
value =  s
optarg = Huber
surname       =  Huber
given name    = 
date of birth = 

Diesen Fehler vermeidet man indem man Zeichenketten, die von "whitespace", also einem Leerzeichen oder einem TAB, unterbrochen ist, mit Anführungszeichen einfaßt. Das folgende Beispiel zeigt, wie das gemeint ist:

# sh gtopt.sh -s "Huber Maier" -g Hugo -b 05.07.1988
value =  s
optarg = Huber Maier
value =  g
optarg = Hugo
value =  b
optarg = 05.07.1988
surname       =  Huber Maier
given name    =  Hugo
date of birth =  05.07.1988

Arbeiten mit Dateien

Nicht, daß es mir ein Bedürfnis wäre aber ich komme selbst immer wieder in die Verlegenheit Dateien zu verarbeiten. Mal Zeilenweise, mal Wort für Wort. Dabei habe ich aber eine etwas eigenartige Definition für den Begriff Wort. Je nachdem, wie das Problem eben liegt oder besser, wie man es sich zurechtgelegt hat, muß man mit unterschiedlichen Methoden an die Sache herangehen.

Zeile für Zeile

Der wohl einfachste Fall ist, wenn man die Datei die man verarbeiten will schon vorher kennt. Dann geht das etwas so:

#!/bin/sh

while read line ; do
   echo "---> "$line
done < /etc/fstab

Für viele kleine Problemchen ist dieser Dreizeiler sicher die Lösung. Aber man kann das noch verfeinern. Man könnte zum Beispiel jede Zeile Spalte für Spalte zerlegen:

#!/bin/sh

df | while read line
do
   # /dev/hda11 1040568 735396 305172 71% /data
   device=`echo $line | cut -d " " -f1`
   usage=`echo $line | cut -d " " -f5`
   mnt_pt=`echo $line | cut -d " " -f6`

   echo -n "Das device "$device" ist am Mount-Point "$mnt_pt
   echo " eingehängt. Es ist zu "$usage" gefüllt."
done

In Verbindung mit dynamischen Arrrays könnte man so zum Beispiel eine interne Tabelle aufbauen, die man frei indizieren kann.

Wort für Wort

Wenn man schön strukturierte Werte in Reih und Glied in einer Datei stehen hat, dann lassen sie sich sehr schön Element für Element verarbeiten, wie das folgende Beispiel zeigt. Zunächst einmal müssen wir jedoch eine passende Datei erzeugen:

ls > my_file

Und dann können wir diese Datei auch verarbeiten:

#!/bin/sh

for i in $(cat my_file); do
    echo "---> "$i
done

Es geht aber auch anders. Im Grunde ist es ja egal wo der Zeichenstrom herkommt. Wichtig ist nur, daß die einzelnen Worte durch sog. Whitespaces, also Leerzeichen oder TAB getrennt sind. Zwischen den runden Klammern mit dem führenden $-Zeichen geht es einzig darum einzelne Worte auszugeben. Und so könnte die for-Schleife auch so aussehen:

#!/bin/sh

for i in $(ls); do
    echo "---> "$i
done

Zwischen diesen beiden Klammern kann man nun allerhand treiben. Hier nur eine kleine Einstimmung auf das, was möglich ist:

#!/bin/sh

for i in $(df | cut -b 57-75); do
    echo "---> "$i
done

File-Descriptoren

Die Eingabe aus einer Datei auch so umleiten, daß sie gelesen werden kann, als käme diese Eingabe geradewegs von der Standardeingabe - stdin:

#!/bin/sh

#
# zunächst den stdin in dem file-descriptor 3 sichern
#
exec 3<&0
#
# jetzt lassen wir den file-descriptor 0 auf /etc/fstab zeigen
#
exec 0</etc/fstab

while read line; do
    echo "---> "$line
done
#
# und zum Abschluß stellen wir bei den file-descriptoren den Orginalzustand
# wieder her. Das nennt man Aufräumen!
#
exec 0<&3

Das folgende Beispiel habe ich aus den Usenet News von dem Kollegen Dan Mercer. Um es besser zu verstehen sollten wir damit ein wenig herumbasteln:

#!/bin/sh

exec 3>/tmp/t$$
exec 4</tmp/t$$
exec 5</tmp/t$$
exec 6</tmp/t$$
exec 7</tmp/t$$
exec 8</tmp/t$$
exec 9</tmp/t$$

rm -f /tmp/t$$

echo "Katze" >&3
echo "Hase" >&3
echo "Gockel" >&3
echo "Hund">&3
echo "Fuchs" >&3
cat /tmp/t$$

sort <&4
echo "===================================="
sort <&5
echo "===================================="
sort <&6
echo "===================================="
sort <&7
echo "===================================="
sort <&8
echo "===================================="
sort <&9

Was passiert da oben? Schon ein bisserl schräg!?! Es wird also eine Datei erzeugt und der File-Descriptor der dazu verwendet wird hat die Nummer 3. 0, 1 und 2 sind schon von stdin, stdout und stderr belegt. Danach öffenen wir die Datei gleich sechs mal zum Lesen. Und sogleich löschen wir die Datei wieder aus dem File-System. Die File-Descriptoren sind aber noch da. Sie sind alle mit den virtuellen File-System verbandelt und dort werden die Daten gepuffert obwohl die Datei aus dem File-System bereits entfernt ist. Pro File-Descriptor können wir einmal bis EOF lesen. Das können wir genau einmal so machen.

Kontrolle über Prozesse

Häufig verwenden wir Shell-Scripten um Programme zu starten. Oft ist es dabei wichtig sicherzustellen, daß so ein Programm nur einmal läuft.

Am billigsten ist das wenn ein Programm seine eigene PID in eine pid-Datei schreibt. In vielen Fällen erzeugen Programme ihre pid-Dateien in dem Verzeichnis /var/run. Es besteht aber kein Zwang, das genauso zu machen. Die Datenbank PostgreSQL schreibt seine pid-Datei in das Verzeichnis, in dem die Datenbank liegt. I der pid-Datei steht nur die PID, mehr nicht.

Wenn ein Programm diese pid-Datei aber nicht von selbst anlegt, dann müssen wir nachhelfen. Dazu müssen wir das Programm von einem Shell-Script aus starten und danach die PID bestimmen und in eine Datei schreiben. Das könnte dann so aussehen:

#!/bin/sh

/usr/X11R6/bin/xclock &
let xclpid=`ps -ef | grep 1185 | grep xclock | egrep -v grep | cut -b 8-14 | sed -e 's/ //g'`
echo $xclpid > xclock.pid

Danach steht in der Datei xclock.pid die PID des Programms. Mit den folgenden Zeilen kriegen wir die xclock wieder los:

#!/bin/sh

xclpid=`cat xclock.pid`
kill -1 $xclpid

Und jetzt wäre es noch ganz angenehm, wenn wir das in einem Script zum Starten und Stoppen richtig verpacken könnten. Das geht etwa so:

#!/bin/sh

XCLOCK_BIN=/usr/X11R6/bin/xclock
PROG_BNM=`/bin/basename $XCLOCK_BIN`

OS_TYPE=`uname -s`
case $OS_TYPE in
    Linux | HP-UX | AIX )
        PS_FLAG=-ef
        ;;
    BSD )
        PS_FLAG=agux
        ;;
esac

case $1 in
    start )
        exec $XCLOCK_BIN &
        let xclpid=`ps $PS_FLAG | grep $$ | grep $PROG_BNM | egrep -v grep | cut -b 8-14 | sed -e 's/ //g'`
        echo $xclpid > xclock.pid
        ;;
    stop )
        xclpid=`cat xclock.pid`
        kill -1 $xclpid
        ;;
    * ) echo
        echo "usage: " $0 "[start|stop]"
        echo
        ;;
esac

exit

Und was bedeutet das jetzt? Das meiste können Sie sich zusammenreimen. Nur die Zeile mit dem ps-Kommando bedarf wohl ein wenig Erklärung:

let xclpid=`ps $PS_FLAG | grep $$ | grep $PROG_BNM | egrep -v grep | cut -b 8-14 | sed -e 's/ //g'`

Ist eine Kaskade aus einzelnen Kommandos. Eines übergibt seine Ausgabe in die Eingabe des nächsten. Zuerst kommt das ps-Kommando. Das gibt eine Liste der laufenden Programme auf der Standardausgabe aus. Je nachdem welches UNIX-Derivat auf Ihrem Rechner läuft unterscheidet sich die Parameterliste von ps-Kommando. Bei System V UNIX-Derivaten verwenden wir ps -ef und bei BSD UNIX-Derivaten verwenden wir ps agux (ohne Minus-Zeichen (-)). Als Ergebnis erhalten wir eine Liste der laufenden Prozesse die wie eine Tabelle aussieht. In der zweiten Spalte dieser Tabelle ist die PID aufgeführt. Damit wir diese eine PID unseres gerade gestarteten Programms erhalten müssen wir erst mal die eine Zeile mit dem Eintrag unseres Programms heraus filtern. Wir gehen dabei zunächst immer davon aus, daß unser Programm wirklich nur einmal läuft und zwar nachdem es von uns gestartet wurde. Dieses Herausfiltern erledigen wir mit dem grep-Kommando. Grep filtert alle Ereignisse, die dem pattern entsprechen. grep filtert entweder eine Datei, deren Namen wir auch noch angeben. Wenn kein Dateiname angegeben ist, dann wartet grep auf einen Zeichenstrom von der Standardeingabe stdin. Mit einer Dateiangabe sieht ein einfacher Aufruf von grep so aus

grep PATH /etc/profile

grep filtert alle Vorkommnisse der Zeichenkette PATH aus der Datei /etc/profile.

Um mit grep einen Zeichenstrom vom stdin zu filtern geht man so vor:

cat /etc/profile | grep PATH

Das Ergebnis ist das gleiche. In unserem Beispiel von oben wird die Liste, die ps ausgibt gefiltert. Das sieht eben so aus:

ps $PS_FLAG | grep $$ |

Die Shell löst erst mal die Variablen auf und ersetzt sie durch die eigentlichen Werte. Bei einem UNIX System V sähe es dann so aus:

ps -ef | grep 1234 # vorausgesetzt die PID des gerade laufenden Prozesses ist 1234.

$$ ist die PID des aktuellen Prozesses. Und unser gerade laufender Prozess hat natürlich "child-Prozesse"

Umgang mit Signalen

UNIX-System bieten eine Vielzahl Mechnismen für die Prozeß-Kommunikation. Eines von Ihnen sind Signale. Signale sind "atomare" Botschaften, die vom Betriebssystem an den jeweiligen Prozeß zugestellt werden. Signale sind insofern atomar, als sie mit keiner weiteren Botschaft befrachtet werden können. Das Signal selbst ist die Botschaft.

Wer schon öfter mit UNIX-Systemen gearbeitet hat, der weiß wie Signale verschickt werden können. Mit dem Kommando kill versendet man sie. Das ist aber nicht alles. kill benötigt mindestens zwei Parameter. Der erste Parameter, den wir angeben ist, welches Signal wir verschicken. Eine Liste der Signale finden wir in der Datei signal.h. Und das sieht etwa so aus:

Signal	Zahlenwert	Signal	Zahlenwert	Signal	Zahlenwert
SIGHUP	1	SIGSEGV	11	SIGTTOU	22
SIGINT	2	SIGUSR2	12	SIGURG	23
SIGQUIT	3	SIGPIPE	13	SIGXCPU	24
SIGILL	4	SIGALRM	14	SIGXFSZ	25
SIGTRAP	5	SIGTERM	15	SIGVTALRM	26
SIGABRT	6	SIGSTKFLT	16	SIGPROF	27
SIGIOT	6	SIGCHLD	17	SIGWINCH	28
SIGBUS	7	SIGCONT	18	SIGIO	29
SIGFPE	8	SIGSTOP	19	SIGPWR	30
SIGKILL	9	SIGTSTP	20	SIGSYS	31
SIGUSR1	10	SIGTTIN	21	SIGUNUSED	31

So, oder so ähnlich sieht die Liste der Signale in der Datei signal.h aus. Das kann sich zwischen unterschiedlichen UNIX-Derivaten in hinteren Teil der Tabelle etwas unterscheiden. Die Signale, die wir verschicken können, sind nur wenige. Am besten wir beschränken uns auf SIGHUP, SIGUSR1 und SIGUSR2.

Im Gegensatz zu den vorigen Beispielen werde ich dieses ein bisserl ausführlicher erklären: Damit man dem Beispiel-Script ein Signal schicken kann muß man seine Prozeß-ID (PID) erfahren. Dies geht auf unterschiedliche Arten. Einmal könnten wir die PID mit dem Kommando ps ermitteln. Das Script weiß seine PID aber auch selber. Wir müssen sie nur ausgeben. Die nehmen wir dann und schicken an den Prozeß mit dieser PID das Signal. Jetzt aber das Script:

#!/bin/sh

servus()
{
    echo "hello world"
    exit
}

trap servus 1

stop=false

while [[ $stop != true ]]; do
    sleep 1
    echo "sleep - "$$
done

Mit $$ erhalten wir die PID des laufenden Scripts. Und an diese PID schicken wir dann das Signal. Z. B.:

kill -1 

Wobei wir PID durch die wirkliche PID ersetzen.

Multitasking

folgt demnächst

Modulare Programmierung

Bei kleinen Scripten können wir noch drauf los programmieren. Häufig sind Scripten ja auch nur ein paar Zeilen lang und je nach Übung machen wir uns Scripten für den Einmalgebrauch. Manchmal werden die Scripten aber länger. Und spätestens wenn sich abzeichnet, dass das eigentlich gar nicht mehr ein "kleines Script" sondern eigentlich schon ein richtiges Programm mit vielen hundert Zeilen wird, dann sollten wir entsprechende Vorkehrungen treffen.

An dieser Stelle ist also ein Minimum an "Software Engineering" notwendig. Sonst wird uns das Script aus dem Ruder laufen. Ausserdem ereignet es sich vermehrt, dass wir Funktionen immer wieder benötigen. Warum also sollten wir eine Funktion dreimal hinschreiben, wenn wir sie dreimal brauchen??? Jetzt ist es soweit, dass wir Funktionen einsetzen werden.

Funktionen

Wenn wir also ein Stück Code immer wieder benötigen, dann sollten wir es in eine Funktion auslagern. Was sage ich? Sollen? Müssen! Ich möchte es an dieser Stelle gleich als unmittelbaren Zwang an jeden Programmierer weitergeben. Wer Bandwurmcode und/oder Spaghetti Code schreibt, der gehört nicht zur Zunft und sollte sich schnell wieder in die Hobby-Ecke verkriechen. Dabei spielt es keine Rolle ob er/sie einen akademischen Titel mit sich herumschleppt. Wer professionell arbeitet segmentiert seinen Code in Funktionen b.z.w Prozeduren.

Begriffsdefinition

Es mag sicher den einen oder anderen Informatiker geben, der mir hier jetzt am liebsten widersprechen möchte.
Gut, dann widersprich mir, aber bitte aussagekräftig. Ansonst mögest Du für immer schweigen

Funktionen

Jetzt geht's zurück in die Schule. Ungefähr die siebte Jahrgangsstufe. Erinnern Sie sich noch? Nachdem wir in Mathematik die Terme soweit abgehakt hatten hat uns der Mathelehrer mit linearen Funktionen überrascht. So nach dem Muster y=a*x+t Wir setzen also ein paar Werte ein und kriegen dafür ein Ergebnis. Und eine Funktion beim Programmieren funktioniert ganz genauso. Dieses Verfahren nennt man auch Call-By-Value. Das heisst, dass die Werte direkt übergeben werden. Dann wird innerhalb der Funktion irgendetwas damit gemacht, hin- und hergerechnet und dann kommt es zu einem Ergebnis. Dieses Ergebnis wird dann mit dem Aufruf "return" zurückgegeben. Das Return entspricht quasi der rechten Hälfte des Gleichheitszeichens "="

Eine Funktion beim Programmieren funktioniert praktisch genauso. Die Werte, die auf der rechten Seite des Gleichheitszeichens (Zuweisungsoperator) verarbeitet werden, nennt man Parameter. Hier kommt es oft zur Begriffsverwirrung. Sehr häufig wird hier von Argumenten gesprochen. Um Argumente handelt es sich aber nur solange wir nicht zur Tat schreiten. Solange wir also die Funktion nur definieren und die Werte nur beschreiben, bestenfalls hypothetisch besetzen sprechen wir von den Platzhaltern für diese Werte von Argumenten. In dem Moment, in dem wir aber die Funktion tatsächlich aufrufen und wirkliche Werte zum Rechnen übergeben, sind das die Parameter.

Im einfachsten Fall haben Funktionen genau einen Parameter. Sie liefern immer genau ein Ergebnis.

Prozeduren

Prozeduren haben die unangenehme Eigenschaft, dass sie mehrere Ergebnisse liefern. Das geht dann freilich nicht mehr einfach über den Zuweisungsoperator b.z.w. durch die Rückgabe über den return-Aufruf. Vielmehr gehen die Ergebnisse auf den selben Weg zurück, auf dem die Parameter gekommen sind. Die Parameter werden sozusagen verändert und die veränderten Werte sind die Ergebnisse. Gleichwohl liefern Prozeduren über den return-Aufruf etwas zurück. Nämlich eine Meldung, ob die Verarbeitung gut gegangen ist. Diese Rückgabe kann beliebig verfeinert werden und sollte einer sinnvollen Semantik folgen.

Einige Parameter werden nicht direkt übergeben. Es können alle sein, es können aber auch nur einige sein, die nicht direkt, also mit Call-By-Value übergeben werden. Die Übergabe solcher Parameter erfolgt indem man der Prozedur sagt wo der Wert, um den es geht, gespeichert ist. Man übergibt also eine Referenz. Und daher nennt man diese Art der Parameterübergabe auch Call-By-Reference.

Methoden

Jetzt werden freilich die ganzen objektorientierten Kollegen fragen wo denn das allerwichtigste bleibt, die Methoden?!?.

Ganz einfach!

Die habe hier eigentlich gar nichts zu suchen und werden nur der Vollständigkeit halber behandelt.

Wenn man ein Objekt machen will, dann behandelt man eine Datenstruktur und die Funktionen und Prozeduren, die man über diese Datenstruktur anwendet als eine Einheit. Durch diese Vereinheitlichung macht Funktionen und Prozeduren zur Methode. Jetzt ist noch die Frage, wie diese Vereinheitlichung stattfindet. In der Shell-Programmierung findet sie gar nicht statt!

Und mal ehrlich. Ziemlich oft macht das objekt orientierte Paradigma auch gar keinen Sinn. Deshalb müssen wir ein bisserl was an den Haaren herbeiziehen, damit wir endlich die Anatomie einer Klasse und eines Objektes beschreiben können und letztlich zu der Erkenntniss gelangen, wie aus einer Funktion eine Methode wird.

Dazu nehmen wir erst mal die Programmiersprache C. Egal welches, K&R oder ANSI. Egal ob ANSI 89 oder ANSI99. Völlig wurscht.

Erst mal denken wir und ein "Ding" das wir mit Hilfe einer Datenstruktur beschreiben möchten. Wenn wir mal in modernen Strukturen denken, dann nehmen wir doch die "human resource". Also dieses Ding, die "human resource" nämlich hat ein paar Eigenschaften. Sie hat

• eine Kompetenz,
• eine Authorität,
• eine Verantwortung,
• eine Gehaltsspanne,
• eine Verfügbarkeit,
• eine Leistung,

Und sie hat was weiss ich noch. Im nächsten Schritt müssen wir uns noch darüber Gedanken machen, wie wir diese Eigenschaften genau beschreiben. Diese Eigenschaften verfügen über eine "gewisse" Natur. Und diese natur müssen wir so beschreiben, dass wir den richtigen Datentyp dafür auswählen.

Soweit die für's Erste die Datenstruktur. Als nächstes kommen die Funktionen und Prozeduren, deren Anwendung im Zusammenhang mit der "human resource" Sinn machen.

Vielleicht interessiert uns die Effizienz. Die können wir aber errechnen indem wir den Quotienten aus Gehalt und Leistung. Das Gehalt kriegen wir sicher über den Umweg über die tatsächliche Person, die diese "human Resource" ausmacht.

Brrrrr, ich weiss, das ist alles ziemlich zynisch.

Wenn ich also nun in C einen Zeiger auf eine Funktion mache, dann kann ich die Funktion aufrufen indem ich den Zeiger de-referenziere. Und wenn ich diesen Zeiger zum Bestandteil meiner Datenstruktur mache wird aus der Funktion eine Methode. Tatsächlich ist die Funktion immer noch eine Funktion, und zwar per Definition.

Aber Methode hört sich doch viel schöner an, oder?

Am Ende ist Objektorientierung nichts anderes als eine bestimmte Sichtweise. Ob ich nun den Zeiger auf die Funktion zum Element meiner Datenstruktur mache ist reine Haarespalterei. Und diese Haarespalterrei wird umso energischer betrieben je schlechter die Programmierer sind. Die meinen sie müssten ersatzweise zeigen wieviel Fremdworte aus diesem Gebiet sie auswendig wissen und möglichst gleichzeitig dem Gesprächspartner um die Ohren hauen können.

Und jetzt wissen wir also auch noch was eine Methode ist.

Aber wir wissen immer noch nicht wie wir eine Funktion in einem Shell-Programm hinschreiben. Damit das ganze nicht so zwanghaft wird, werde ich die folgenden Kapitel ein wenig durchmischen. Es ist nämlich immer wieder das Problem das Ganze mit einem halbwegs nachvollziehbarem Beispiel zu unterfüttern.

Als erstes machen wir einen kleinen Rahmen in unser Terminal. Egal ob wir ein altes DEC VT220 oder ein X-Term auf vor uns haben. Unser Programm sollte ungefähr gleich aussehen. Daher machen wir um alles, was wir in so einem Programm veranstalten einen Rahmen.

Bevor wir irgendwas auf den Bildschirm zeichnen, machen wir den Bildschirm sauber. Das geschieht so:

    clear

Und der Rahmen sieht dann so aus:

    clear
    echo "+------------------------------------------------------------------------------+"
    echo "|+----------------------------------------------------------------------------+|"
    let count=0
    while (( count < 19 )); do
        echo "||                                                                            ||"
        let count=count+1
    done
    echo "|+----------------------------------------------------------------------------+|"
    echo "+------------------------------------------------------------------------------+"

Als nächstes sehen, dass wir diesen Rahmen vielleicht ziemlich oft brauchen. Daher verpacken wir ihn in eine Funktion und rufen fortan nur noch diese Funktion.

big_frm()
{
    clear
    echo "+------------------------------------------------------------------------------+"
    echo "|+----------------------------------------------------------------------------+|"
    let count=0
    while (( count < 19 )); do
        echo "||                                                                            ||"
        let count=count+1
    done
    echo "|+----------------------------------------------------------------------------+|"
    echo "+------------------------------------------------------------------------------+"
}

Funktionen wie diese stellen wir ans obere Ende unseres Quelltextes. Das "main", also das Hauptprogramm steht vorzugsweise am untersten Ende unseres Quelltextes. Ich mache das immer so, dass ich ganzganzganz unten das Wort main hinschreibe und gleich darüber eine Funktion mit dem Namen main

In dieser main-Funktion führe ich dann die wichtigsten Dinge aus und steuere dort den zentralen Flow of Control

Ein Shell-Script mit Funktionen besteht aus einem Haupt-Programm und eben den Funktionen. Die Befehle des Haupt-Programmes stehen ganzganz unten. Am obersten Ende des Quelltextes steht das she-bang, dann die "includes", dann die Funktionen und dann, zu allerletzt die Aufrufe des eigentlichen Shell-Scripts. Bei mir ist das nur ein einziges Kommando. Nämlich der Aufruf der Funktion main.

Im Laufe der folgenden drei Kapitel werden die Funktionen immer aufwendiger. Ich möchte in diesem Kapitel keinen undurchsichtigen Exzess hinschreiben und den Sie im folgenden auf sich alleine gestellt lassen. Lieber werde ich in den folgenden Kapiteln immer wieder auf das Thema Funktionen b.z.w. IO oder sonstwas zurückblenden, so dass immer wieder der Zusammenhang klar wird.

Benutzerschnittstellen und I/O

Manchmal müssen wir vom Programm aus den Anwender um eine Entscheidung bitten. Bei Shell-Scripten kommt es recht häufig vor, dass man eine numerierte Auswahl präsentiert und dann den Anwender bittet die Auswahl zu treffen indem er die entsprechende Zahl eingibt. Das sieht dann z. B. so aus:

#!/bin/sh

big_frm()
{
    #
    # loescht den Bildschirm
    #
    clear
    #
    # Jetzt wird ein Rahmen auf den Bildschirm b.z.w. das xterm gepinselt.
    #
    echo "+------------------------------------------------------------------------------+"
    echo "|+----------------------------------------------------------------------------+|"
    let count=0
    while (( count < 19 )); do
        echo "||                                                                            ||"
        let count=count+1
    done
    echo "|+----------------------------------------------------------------------------+|"
    echo "+------------------------------------------------------------------------------+"
}
abfrage()
{
    #
    # Also erst mal den Rahmen auf einen sauberen Bildschirm pinseln
    #
    big_frm
    
    #
    # Innerhalb des Rahmens sollte alles an den richtigen Platz geschrieben
    # werden. Um den Cursor zu positionieren verwenden wir "tput cup x y"
    # Danach koennen wir schreiben.
    #
    tput cup 8 20
    echo "Waehlen Sie eine Frucht aus"

    done=false

    while [[ $done = false ]]; do
        done=true
        tput cup 10 20
        echo "1) Apfel"
        tput cup 11 20
        echo "2) Birne"
        tput cup 12 20
        echo "3) Pflaume"
        tput cup 13 20
        echo "4) Mirabelle"

        tput cup 15 20
        echo "Ihre Auswahl: "

        tput cup 15 34
        read ANTWORT

        tput cup 23 0

        case $ANTWORT in
            1 ) ;;
            2 ) ;;
            3 ) ;;
            4 ) ;;
            * ) echo "ungueltige Eingabe"
                done=false
                ;;
        esac
    done
    return $ANTWORT # Wir koennen leider nur numerische Werte zurückgeben.
}

main()
{
    TTYSAVE=`stty -g`  # alle Terminal-Settings abfragen und in der Variablen
                       # TTYSAVE speichern
    abfrage

    #
    # Der Umstand, dass wir nur numerische Variablen mit Return zurückliefern
    # können macht zunächst diese erneute Fallunterscheidung nötig.
    #
    case $? in
        1 ) FRUCHT=Apfel
            ;;
        2 ) FRUCHT=Birne
            ;;
        3 ) FRUCHT=Pflaume
            ;;
        4 ) FRUCHT=Mirabelle
            ;;
        esac

    echo $FRUCHT

    stty $TTYSAVE      # alle ursprünglichen Terminal-Settings wiederherstellen
}

main

Die Quellen von using_read.sh

Funktionen wie diese stellen wir ans obere Ende unseres Quelltextes. Das "main", also das Hauptprogramm steht vorzugsweise am untersten Ende unseres Quelltextes. Ich mache das immer so, dass ich ganzganzganz unten das Wort main hinschreibe und gleich darüber eine Funktion mit dem Namen main

Mehr Benutzerschnittstellen und I/O

Mit dem vorigen Kapitel haben wir ja schon eine erste, eher primitive Benutzerschnittstelle gesehen. manchmal tut's das wirklich. Manchmal wollen wir aber sowohl die Ein-/Ausgabe als auch den Anwender genau kontrollieren. Das ist dann der Fall, wenn wir keine Fehler zulassen wollen.

An dieser Stelle stelle ich Ihnen vor wie man mit Shell-Scripten Benutzerschnittstellen baut, die ähnlich wie "curses" aussehen.

Der Schlüssel zu solchen Benutzerschnittstellen ist das Kommando tput. In diesen Beispielen verwende ich nur einen kleinen Teil der Möglichkeiten von tput, weil es sonst wirklich den Rahmen sprengen wird, wenn ich jedes dieser Kommandos bis ins Detail bearbeite.



Die hier abgebildete Benutzerschnittstelle läuft in einem X-Term das folgendermassen aufgerufen wird:

xterm -fg yellow -bg blue -cr red

Der Cursor steht also auf dem ersten Auswahlfeld. Daher ist das Feld links neben der Auswahl "English" auch rot.

Die Invertierung des Textes, also blaue Schrift auf gelbem Grund erreicht mit dem Kommando

tput smso

Und wenn man wieder normal weiterschreiben will, also in diesem Fall gelbe Schrift auf blauem Grund dann erreichen wir das mit dem Kommando

tput rmso

Wenn man also solche Eingabefelder von Vorne herein richtig darstellen will, dann muss man die Benutzerschnittstelle hinmalen bevor man mit dem Benutzer wieder in Interaktion tritt. Dazu führt man den Cursor an die gewünschte Stelle und zeichnet das Feld. Das geht z. B. so:

#!/bin/sh
clear
#
# Cursor an die gewünschte Stelle plazieren
#
tput cup 10 10 
#
# Eingabefeld begrenzen. Das geschient üblicherweise mit eckigen Klammern
#
echo "[     ]"
#
# Den Cursor in die Begrenzung plazieren
#
tput cup 10 11
#
# Die Farbe wechseln
#
tput smso
#
# das Feld malen
#
echo "     "
#
# Die Farbe zurücksetzen
#
tput rmso
#
# den Cursor da plazieren, wo er hingehört
#
tput cup 23 0

Naja, das war so ein Anfang. Aber irgendwo muss man ja anfangen. Jetzt haben wir also ein Feld in das wir was einfügen könnten, aber der Cursor steht ganz wo anders. Jetzt müssen wir allmählich das ganze Programmierportfolio, das wir oben gelernt haben, auspacken.

Zunächst also wieder ein main. Dann die main-Funktion und dann geht's los. Hier wollen wir auch gleich mit der konsequenten Modularisierung unserer Quellen anfangen. Es wird also auch Quell-Moduln geben, die wir am Besten in einem Verzeichnis ./lib verstauen.

Zunächst verwenden wir hierfür die folgenden Dateien:

Die Bibliothek gadget.sh
Die Bibliothek io.sh

Ich möchte mich hier gleich für die äussere Form dieser Dateien entschuldigen. Zum jetzigen Zeitpunkt stammen sie so wie sie sind aus meinem Fundus und wurden noch nicht für dieses Tutorial aufbereitet. Im Laufe der Zeit werde ich die Quelltexte noch überarbeiten.

Aber wie kriegen wir diese Bibliotheken in unser Programm? Das ist so einfach, dass es schon fast peinlich ist:

#!/bin/sh
init_this()
{
    #
    # Natuerlich findet in dieser init-Funktion noch viel mehr statt. Aber um
    # zu zeigen, wie man Bibliotheken anzieht stehen eben nur diese zwei Zeilen
    # da.
    # Es wird vorausgesetzt, dass Sie die Bibliotheken in einem lokalen
    # Verzeichnis mit dem Namen "lib" gespeichert haben.
    #
    . lib/gadget.sh
    . lib/io.sh
}
main()
{
    TTYSAVE=`stty -g`  # alle Terminal-Settings abfragen und in der Variablen
                       # TTYSAVE speichern
    init_this
    stty $TTYSAVE      # alle ursprünglichen Terminal-Settings wiederherstellen
}
main

Das Heranziehen solcher Dateien wie z. B. dieser Bibliotheken nennt man "sourcing". Und in bestem "denglish" würde man dan wohl sagen, die Bibliotheken würden (jetzt kommt's) "gesourced" :-)))

So haben wir jetzt zwar gesehen, wie diese Bibliotheken eingebunden werden. Tatsächlich handelt es sich hier um eine "textuelle Ersetzung" analog zu den #include Präprozessoranweisungen in der Programmiersprache "C"

So eine Art Togglebutton

Jetzt aber wieder ein bisserl zum Thema I/O. Ich glaube es wäre am Besten, wir hangeln uns an dem Beispiel aus dem Bild von weiter oben entlang. Dort wird nach der bevorzugten Sprache gefragt. Und das geht so.
1. Initialisiseren
2. Bildschirm aufbauen (Benutzerschnittstelle malen)
• Es besteht die Auswahl zwischen "English" und "Deutsch"
• Unten besteht die Auswahl zwischen [Ok] und [Cancel]
3. Cursor wieder auf das erste Feld plazieren
4. Eingabe abwarten.
5. Nach der Eingabe wird der Cursor auf das nächste Feld geführt.
6. Falls in das zweite Feld ein "X" eingegeben wird dann
• Prüfen, ob im ersten Auswahlfeld auch schon ein "X" gesetzt ist.
• Falls ja,
• Das "X" aus dem ersten Auswahlfeld zurücksetzen.
• Falls überhaupt in irgend ein Feld ein "X" eingegeben wurde, dann
• Dann den Cursor nach dieser Eingabe auf das [Ok]-Feld plazieren.
• sonst
• den Cursor auf das [Cancel]-Feld plazieren

Den Quelltext für lang01.sh finden Sie hier


Ein Eingabefeld

Manchmal ist es sinnvoll, einen Anwender um die Eingabe eines Wortes oder evtl Mehr zu bitten und diese Eingabe genau zu steuern. Dann benötigen wir Eingabefelder mit einer begrenzten Länge und die Möglichkeit nur ganz bestimmte Zeichen zuzulassen. Das geht dann so:

Den Cursor können wir ja schon positionieren. Wenn wir den Cursor jetzt in einem Eingabefeld mitführen wollen, dann müssen wir die Position des Cursors berechnen. Das geht eigentlich recht einfach. Wir müssen nur wissen wo unser Ausgangspunkt ist. Von da an wird nur noch nach rechts jeweils eine Stelle pro eingegebenes Zeichen addiert.

Solange wir für ein Eingabefeld Zeichen lesen, müssen wir jedes eingegebene zeichen einzeln lesen. Dazu müssen wir das Gerät /dev/tty anzapfen. Hierzu müssen wir uns einmal Gedanken machen, wie das unter UNIX eigentlich gedacht ist.

Unter UNIX ist alles eine Datei. Dieser Satz hat eine sehr sehr große Tragweite. Denn auch Geräte (devices) sind nichts weiter als Dateien. Wir können diese Dateien öffnen um daraus zu lesen oder in sie zu schreiben. Es spielt keine Rolle ob wir eine normale Datei verwenden, ob wir einen FIFO verwenden oder eben ein Device. Wir müssen nur eines im Auge behalten. Wenn wir die Eingabe wirklich kontrollieren möchten, dann müssen wir Zeichen für Zeichen lesen. Und das geht so:

stty raw
readchar=`dd if=/dev/tty bs=1 count=1 2>/dev/null`
stty -raw

Das bedeutet folgendes:
• "dd" ist das Kommando. Der Name "dd" steht für "disk dump" dabei handelt es sich wohl um eines der ursprünglichsten Kommandos mit dem man ein Backup durchführte. "dd" ist aber so vielseitig, dass man damit auch noch viele andere Dinge machen kann. Überdies ist "dd" auch heute noch nicht aus dem Backup-Prozedere wegzudenken. Denn damit kann man die Schreib- und Leseabläufe beim Zugriff auf Dateien sehr genau steuern.
• "if" ist der Parameter mit dem das "input file" also die Eingabe-Datei angegeben wird.
• "bs" ist die "block size" damit wird angegeben, wieviel Bytes auf einmal gelesen werden.
• "count" gibt die Anzahl der Blöcke an, die auf einmal gelesen werden.
• "2>/dev/null" leitet alle Ausgaben, die über "stderr" kommen nach /dev/null um
• "/dev/null" das ist der "bit bucket" Alles was dahin umgeleitet wird ist weg. Unwiederbringlich.
• "stty raw" verstellt die Terminaleinstellungen so, dass wir wirklich alles ungefiltert zu greifen kriegen.
• "stty -raw" Stellt die Terminaleinstellungen wieder zurück.

Das Script sieht dann so aus:



Als nächstes wollen wir das für 15 Zeichen machen. Zumindest in unserem Beispiel geht das 15 Zeichen lang so. 15 Zeichen b.z.w. bis der Anwender auf [RETURN] klopft. Inzwischen haben wir schon alles zusammen, was wir als Parameter an die Funktion übergeben, mit der wir das Eingabefeld auslesen:

• Wieviel Zeichen wollen wir lesen?
• Was für Zeichen wollen wir lesen?
• Zeichen,
• Zahlen
• alles
• Die "X"- und "Y"-Koordinaten des Eingabefeldes

Und dann sieht der Aufruf der Funktion so aus:

getentry <Anzahl d. Zeichen> <num|char|all> <X> <Y>

Die Funktion getentry() ruft solange die Funktion getpc() auf wie Zeichen erwartet werden. Und das geht solange, wie eben noch nicht die angegebene Anzahl der Zeichen eingegeben wurde oder [RETURN] gedrückt wurde. Oder anders. getentry() liest bis [RETURN] gedrückt wird oder bis genausoviele Zeichen eingegeben wurden wie im ersten Parameter angegeben wurde.

Jedes Zeichen wird dann behandelt. In der vorliegenden Version ist diese Behandlung recht einfach und sicherlich auch unzureichend. Erst einmal wird geprüft, ob es sich um einen carriage-return handelt und wenn ja, dann ist die Funktion ja fertig. Wenn nein, dann muss immer noch geprüft werden, ob die Anzahl der zu lesenden Zeichen erreicht wurde.

Und dann gibt's da noch einige Sonderfälle:

• Wenn man von /dev/tty liest, dann kriegt man ja auch alle möglichen anderen Codes. Z. B. die von den Cursor-Tasten.
• Ctrl-C funktioniert nicht mehr.
• etc
• und das alles unterscheidet sich von UNIX-Derivat zu UNIX-Derivat.
Ich kann das leider nicht erschöpfend für abhandeln. Ich habe halt nur einen Linux Rechner zur Verfügung. Sobald ich einen finde, der mir eine HP, eine Sun, eine RS/6000 und eine SGI hinstellt (von mir aus auch eine alte) mache ich eine anständige Bibliothek daraus. (SCO werde ich nur gegen Bezahlung unterstützen)

Den Quelltext für entry_fld.sh finden Sie hier


Eine Passwortabfrage

Eigentlich reicht es ja, wenn wir einfach die Ausgabe unterdrücken während wir ein Passwort abfragen. Das geht dann so:

stty -echo

Und schon wird das, was wir tippen nicht mehr angezeigt. Und wenn wir es wieder sichtbar haben wollen, dann brauchen wir nur folgendes einzugeben:

stty echo

Und schon ist alles wieder da.

Das ist zwar praktisch und in vielen Fällen auch völlig ausreichend. Aber manchmal haben wir es eben nicht mit Systemadministratoren, sondern mit normalen Anwendern zu tun. Und normale Anwender brauchen Führung. Das heißt: Der Systemadministrator hat eine Bringschuld. Er ist gefordert sein Hirn einzuschalten. Vom durchAnwender (auch vom Power-User) dürfen wir das nicht verlangen. Da haben wir die Bringschuld. Wir müssen die Benutzerführung weitgehend wasserdicht machen, sonst kommt es eben zu skurilen Anwendungsfehlern. Und an denen sind immer die Entwickler schuld und nie die Anwender. Das ist einfach so.

Der Anwender braucht eine Rückmeldung für das was er tut. Im Falle der Passworteingabe ist es notwendig, daß wir ihm für jeden Tastendruck ein Zeichen auf dem Bildschirm präsentieren. Im Falle von normalen Eingabefeldern ist das eben das zeichen, das er gerade eingegeben hat und im Falle von Passwortfeldern ist das der übliche "Stern" (asterisk).

Der Weg dahin ist sehr sehr einfach. Wir haben ja bereits das Eingabefeld. Dort müssen wir einfach nur anstelle des gerade eingegebenen Zeichens eben ein Sternchen ausgeben. Die entsprechende Stelle finden Sie in den Kommentaren der Quelltexte. Dazu habe ich zunächst einfach nur die Funktion getentry() abgewandelt, wie ich das oben beschrieben habe. Natürlich könnte man auch einen zusätzlichen Parameter einführen. Z. B. ein "c" für "cleartext" und ein "h" für "hidden", oder wie auch immer. In der Funktion müßte man dann unterscheiden ob man Klartext oder nur den Asterisk ausgibt.

In diesem Beispiel gibt es also zwei fast identische Funktionen. getentry() und getpass(). Und die Anwendung ruft eben die Funktion getpass() um die Eingabe abzugreifen ohne daß diese auf dem Bildschirm sichtbar wird. Das sieht dann so aus:



Den Quelltext für pass_fld.sh finden Sie hier


Zwischendurch was Brauchbares

Jetzt wär's auch noch ganz gut, wenn einmal eine brauchbare Anwendung gezeigt würde.

Stellen Sie sich vor, sie benötigen die Möglichkeit einen Anwender das Passwort ändern zu lassen ohne ihn durch eine komplizierte Kaskade von Menüs zu führen. Gehen wir mal davon aus, daß wir noch mit ganz einfachen Mitteln administrieren. Kein NIS, kein LDAP, kein Kerberos. Das Passwort ist lokal in /etc/shadow gespeichert.

Die Voraussetzungen für diese kleine Anwendung sind also eher einfach. Aber stellen Sie sich vor, wir stellen einem einzelnen Anwender einen PC mit Linux nach Hause. Dort will er nun sein Passwort wechseln. Und da nimmt das Unheil seinen Lauf. Sie erklären ihm, daß eine Shell aufmachen muß und das Kommando /usr/bin/passwd aufrufen muß. Stellen Sie sich nur vor was da alles passieren kann. Der Anwender ruft sicher bald wieder bei Ihnen an und ruft um Hilfe.

Hier ist eine brauchbare Anwendung für das folgende Script. Wir haben die folgenden Anforderungen an das Script:

• Benutzerführung für das Ändern des Passwortes
• Das Passwort darf nicht sichtbar werden
• Das Script muß durch den Anwender einfach aufgerufen werden können

Freilich kann man das auch mit Tcl/Tk machen. Man kann das mit allem möglichem Machen. Von mir aus schreiben Sie die Anwendung mit X11/Motif in C oder sonstwie. Aber hier machen wir's eben mit der Bourne-Shell.

Diesmal benötigen wir nicht ein Eingabefeld sondern drei. Eines für das alte Passwort und zwei für das neue. Wie üblich muß der Anwender das neue Passwort zweimal eingeben, damit er sich nicht aus versehen vertippt. Und dann sollten wir dem Benutzer noch die Fehlermeldungen von /usr/bin/passwd zur Kenntnis bringen.

Weiter gehen wir davon aus, daß unser Anwender mit einer X11-basierten graphischen Benutzeroberfläche arbeitet. Denn in diesem Beispiel werden wir das Script in einem "X-Term" laufen lassen.

Erst mal basteln wir einen Dummy, um zu sehen, wie die Benutzerschnittstelle aussehen könnte.

Den Quelltext für chg_pass_dummy.sh finden Sie hier


Dieses Script macht freilich noch gar nichts ausser die einzelnen Felder der Benutzerschnittstelle hinzumalen.

In einem zweiten Schritt wird das Script etwas verfeinert und tut auch schon etwas. Wir verdrahten die einzelnen Felder mit der Funktion getpass() und weisen den Wert den wir aus dem Eingabefeld abgreifen in eine jeweils eigene Variable zu. Zur Kontrolle geben wir zum Schlus in der Funktion main() diese drei Werte aus.

Zwischenzeitlich habe ich eingesehen, dass es nicht sehr hübsch aussieht, wie das Script chg_pass_dummy.sh die Benutzerschnittstelle zeichnet. Daher baut chg_pass_dummy2.sh die Benutzerschnittstelle sukzessive auf.

Den Quelltext für chg_pass_dummy2.sh finden Sie hier


Jetzt wo wir die Passworte in Variablen speichern können tauchen einige Fragen auf:

• Eigentlich müßten wir doch abprüfen ob das alte Passwort korrekt ist!?!
• Was machen wir, wenn der Anwender gar nichts eingibt sondern nur auf [RETURN] drückt?
• Was machen wir, wenn der Anwender das neue Passwort NICHT zweimal gleich eingibt?

So nach und nach verdrahten wir diese zusätzlichen Problemchen. Als erstes müssen wir wohl überprüfen, ob der Anwender bei der Abfrage des alten Kennwortes überhaupt etwas eingegeben hat. Falls er einfach nur auf [RETURN] gedrückt hat, sollten wir ihn fragen, ob er das absichtlich gemacht hat, ob er abbrechen will oder ob er weitermachen will.

In diesem Beispiel schlage ich vor dieses Problem mit einem zusätzlichen Dialog-Fenster zu erledigen. Dadurch stören wir nicht den Bildaufbau im Hauptfenster.

Zunächst jedoch müssen wir überprüfen, ob das Kennwort korrekt ist. Dazu benötigen wir das Programm /usr/bin/passwd. Bevor wir uns darin verfangen müssen wir mit /usr/bin/passwd erst ein wenig herumprobieren. Wie kriegen wir eine brauchbare Meldung von /usr/bin/passwd??? Am besten wir probieren das einfach auf der Shell aus. Also wir tippen passwd und werden aufgefordert unser altes Kennwort einzugeben. Und hier geben wir irgendwelchen Non-Sense ein. Nur nicht das richtige Kennwort.

# passwd Changing password for toni Old Password: passwd: Authentication failure

Als nächstes geben wir das richtige Passwort ein. Und dann?

# passwd Changing password for toni Old Password: New Password:

Und jetzt??? Jetzt hängt das Ding und wartet auf das neue Passwort. Das kann's ja nicht sein. Das Programm passwd gehört dem User root und wir haben nicht mal das Recht ihm ein Signal zu schicken. Aber es gibt Hilfe. Wenn wir hier einfach [CTRL-D] eingeben, dann bricht passwd ab. Und dann kriegen wir zwei völlig unterschiedliche Fehlermeldungen. Das eine mal eben "Authentication failure" und das andere mal "Password change aborted".

Aber wie kriegen wir [CTRL-D] in den Prompt von passwd?

Ein wenig wissen über die Funktionsweise einer Shell (ich meiner eine UNIX-Shell) führt uns weiter. Eine Shell arbeitet in einer Endlosschleife. Darin werden alle zeichen verarbeitet. Die Schleife funktioniert nach dem Muster

while (getc()==TRUE) do{
    ...
}

Und wenn eben eine Eingabe FALSE ist, dann bricht die Schleife ab. [CTRL-D] hat eben genau den Wert 0 (Null) und der entspricht FALSE. Offenbar arbeitet passwd die Eingaben der Anwender genauso ab.

In einem nächsten Schritt wollen wir das in unser Script einbauen. Aber wie?

Dabei hilft uns die Sub-shell Ein einfacher Aufruf von Passwd könnte dann etwa so aussehen:

altes_passwort=blabla
(echo $altes_passwort) | passwd
passwd: Authentication failure

Und nun müssen wir noch die Fehlermeldung abgreifen:

fehlermeldung=`(echo $altes_passwort) | passwd 2>&1`
auth_err=`echo $fehlermeldung | grep "Authentication failure"`
if [[ -z $auth_err ]]; then
    echo "Erfolg"
else
    echo "Fehler"
fi

Und so müssen wir das nun in user Script einbauen. Freilich nicht genau so. Statt der Ausgabe der Worte "Fehler" b.z.w. "Erfolg" müssen wir eine Fehlerbehandlung einbauen und einen entsprechenden Rückgabewert liefern.

Freilich einen numerischen Rückgabewert. Und dann? Dann müssen wir was damit anfangen. Ich schlage vor, dass die Funktion chk_pass() bei Erfolg eine Null (0) liefert und sonst etwas größeres. Und in der Funktion read_pass() machen wir eine Fehlerbehandlung, wenn der Rückgabewert größer Null (0) ist.

if [[ $? -gt 0 ]]; then
    init_pass_UI
    done=false
fi

Hier ist es mal wieder Zeit, daß wir einen funktionsfähigen Quelltext absaugen. Den finden hinter dem folgenden Link:

Den Quelltext für chg_pass_dummy3.sh finden Sie hier


Jetzt muß die Fehlerbehandlung etwas Substanz kriegen. Wir sollten dem Benutzer sagen, daß er etwas falsch gemacht hat und daß er leider nochmal von Vorne anfangen muß. Dazu brauchen wir eine weitere Funktion, die das unserem "user" klarmachen wird. Jetzt sind ein paar Umbauarbeiten fällig. Wir bemerken, dass die Funktion init_pass_UI() irgendwie an der falschen Stelle ist. Sie gehört in die erste Schleife. Denn da wird sie sowieso aufgerufen bevor etwas passiert und sie wird auch wieder aufgerufen, wenn wir das Fenster mit der Fehlermeldung verunstaltet haben:

#
# altes Passwort abfragen
#
done=false
while [[ $done = false ]]; do
    init_pass_UI
    done=true
    tput cup 7 31              # Cursor positionieren
    tput smso
    getpass 15 all 7 31        # Eingabe lesen. Cursorposition relativ zu
                               # diesen Koordinaten nachfuehren
                               # !! Nur "char" also Buchstaben!!
    tput rmso
    if [[ $? -eq 1 ]]; then    # bei Eingabefehlern,  nochmal von Vorne.
        tput cup 21 7
        echo "You entered an invalid character!"
        tput cup 22 7
        echo "Please only use characters."
        done=false
    fi
    altes_passwort=$entry      # Bei erfolg, Wert zuweisen und Loop beenden
    chk_pass $altes_passwort
    if [[ $? -gt 0 ]]; then
        altes_pw_falsch
        init_pass_UI
        done=false
    fi
done

In die Fehlerbehandlung habe ich jetzt den Aufruf der Funktion altes_pw_falsch()

---

Der nachfolgende Text zum Projekt ist sowas von "outdated", dass ich mir schon überlegt habe, ob ich ihn nicht gleich lösche.

Ich behalte ihn aber als Denkstütze. Denn das Projekt möchte ich schon noch machen.

Fragt sich nur wann.

Project

Irgendwie muß man die ganzen Einzelteile, die oben vorgestellt wurden ja auch mal anwenden. Die Beispiele, die bisher gezeigt wurden sind ja sehr abstract und möglicherweise nicht jedermanns geschmack. Hier zeige ich mit einer Anwendung was mit Shellprogrammierung drin ist.

Das folgende Projekt habe ich nicht aus dem Blauen heraus entwickelt. Vielmehr sind die meisten Bestandteile in einem Projekt entstanden, in dem ich für eine UNIX-Netzwerk eine Anwendung entwickeln mußte aber keinen C-Compiler zur Verfügung hatte. Es gab ausreichend Gründe auf den Rechnern nichts zu installieren, was irgendwie systemnah sein würde. Und so mußte ich mit dem auskommen, was da war. Da wäre ein K&R-C-Compiler ohne viel Bibliotheken. Er diente nur zum Übersetzen des Kernels und eben die Shell.

Trotz dieser spartanischen Ausstattung war es notwendig eine möglichst komfortable Benutzerführung zu entwickeln. Da notwendigerweise alles im Terminal, hier im xterm, stattfand sollte die Benutzerführung wenigstens wie Curses aussehen. Und damit fangen die Probleme an.

Hier die Problemlösung:

Erste Worte

Das Stichwort Curses sagt schon, daß wir an den Terminal-Eigenschaften herumschrauben werden. Deshalb fängt das Program mit einer wichtigen Kleinigkeit an:

TTYSAVE=`stty -g`

Und unser Programm hört auf mit den Worten:

stty $TTYSAVE

Diese beiden Zeilen machen unser Terminal wieder Benutzbar, nachdem wir während des Programmierens möglicherweise wichtige Einstellungen geändert haben.

Als nächstes müssen wir uns der Einsicht beugen, daß UNIX-Systeme unterschiedlich sind. Unser Ziel ist es aber, daß sich unser Shell-Programm überall gleich verhält. Daher müssen wir gegebenenfalls eine Fallunterscheidung einbauen, die es uns ermöglicht auf die Eigenheiten der unterschiedlichen UNIX-Derivate einzugehen. Dies wird insbesondere notwedig werden, wenn wir einzelne Zeichen von der Tastatur lesen und ihre Verarbeitung selbst in die Hand nehmen.

os_type=`uname -s`
if [[ $os_type = "Linux" ]]; then
    let r_char=10
elif [[ $os_type = "HP-UX" ]]; then
    let r_char=13
fi

Das hier war nur ein kleiner Ausblick auf das was uns in Sachen Terminalsteuerung noch bevorsteht.

Der große Rahmen

Ein xterm hat 24 Zeilen und 80 Spalten, wenn man es ohne weitere Parameter startet. Danach richten wir uns in diesem Beispiel:

big_frm()
{
    clear
    echo "+------------------------------------------------------------------------------+"
    echo "|+----------------------------------------------------------------------------+|"
    let count=0
    while (( count < 19 )); do
        echo "||                                                                            ||"
        let count=count+1
    done
    echo "|+----------------------------------------------------------------------------+|"
    echo "+------------------------------------------------------------------------------+"
}

Mit big_frm() kriegen wir immer wieder den Bildschirm in Form. So geben wir ihm das richtige Aussehen. Und innerhalb des so gezeichneten Rahmens entsteht dann die eigentliche Benutzerschnittstelle.

---