Kornshell - die AIX standard Shell

Nein, dies ist nicht das einmillionste Tutorium wie man "Hallo Welt" in einer Shell skriptet. So etwas lesen Sie auf Content Farms und anderen Seiten im Internet. Wie auf allen anderen Seiten von SES bekommen Sie Hinweise auf ausgewählte Sachverhalte die sich in der Praxis der Unix Serveradministration als hilfreich erwiesen haben. Der Schwerpunkt liegt dabei auf AIX und das bedeutet Kornshell. Einiges gilt jedoch unisono für alle Shells und somit auch für andere Betriebssysteme.

Wer braucht schon eine standard Shell?

Die Adminstration von *nix und *nux Systemen findet meist in einer Shell statt. Oft lernt man zeitglich mit einem bestimmten Betriebssystem eine bestimmte Shell kennen. Wenn jemand von einem Linux System kommt, ist er z.B. meist die bash Shell gewöhnt. Ein AIX Administrator beginnt mit der Kornshell.. In der Folge ist man dann leicht geneigt die Shell, an die man gewöhnt ist, auch auf anderen Betriebssystemen zu benutzen. Da diese Shells aber z.T. sehr unterschiedlich sind, führt das öfter als man meint zu Problemen. Für die Nutzung der Shell auf AIX Servern heißt es ganz klar: die AIX default Shell ist die Kornshell. Eigentlich muß man das noch weiter einschränken und zwar auf die Kornshell 88. Sie ist die einzige Shell, bei der man sich immer sicher sein kann, daß man beim debuggen von AIX Problemen auch wirklich ein AIX Problem debuggt und nicht ein verstecktes Shellproblem.

Seit ein paar Jahren wird in AIX zusätzlich zur ksh88 die ksh93 ausgeliefert. Nach einigen Qualitätsproblemen am Anfang (sehr beliebt war z.B. das Sperren von Benutzerkonten einfach dadurch, daß man die ksh93 als Login-Shell auswählte) ist sie 2011 so weit, daß man sie benutzen kann. Jedoch bezahlt man die zusätzlichen Funktionen der ksh93 gegenüber der ksh88 damit, daß sie immer noch ein paar Probleme bereitet, die Benutzer der ksh88 so nicht kennen. Ein aktuelles Beispiel für solche Probleme (aus 2010) findet sich z.B. in unserem AIX Board. Eine weitere Einschränkung ist, daß die ksh93 im AIX nicht auf dem letzten Stand der ksh93 ist. Z.B. sind die erweiterten Authentifizierungsfunktionen in der von IBM ausgelieferten ksh93 nicht enthalten. Wer diese braucht muß sich die ksh93 selber kompilieren aber das ist dann nochmal ein ganz anderes Thema. Wir bleiben hier bei den offiziell im AIX auf Medium ausgelieferten Shells.

Nachdem wir die Regel vorgestellt haben, kommt jetzt die unvermeidliche Ausnahme. Die Kornshell unter AIX ist nicht gut geeignet, wenn man z.B. Software mit C Compilern kompilieren möchte. Nicht gut geeignet meint dabei jedoch nicht die Funktion, sondern die Geschwindigkeit. Die Kornshellvarianten von AIX tendieren dazu beim kompilieren eine große Zahl temporäre Dateien in /tmp anzulegen und bremsen die Übersetzung auf diese Weise heftig aus. In diesem Fall ist deshalb die bash aus der IBM Linux Toolbox der ksh vorzuziehen. Es ist einfach schneller man ruft ein ./configure mit der bash auf, als daß man z.B. eine RAM disk anlegt. Aber das war es dann auch schon mit der Ausnahme.

Skriptprogrammierung mit der Kornshell

Gute Administratoren sind in gewisser Weise faule Menschen. Sie sind immer bestrebt ihre Arbeit zu minimieren und sie erreichen dies, indem sie Aufgaben in Shellskripte packen. Dadurch vermeiden sie sowohl endlose Wiederholungen von stupiden Tätigkeiten als auch Fehler bei der manuellen Eingabe von Komandos. Ein guter Administrator kann beim Uneingeweihten leicht den Eindruck erwecken, er hätte nichts zu tun. Aber in der Regel täuscht dieser Eindruck, denn dieses "nichts zu tun" in einem Rechenzentrum geht immer darauf zurück, daß die Systemumgebung gut gepflegt ist und die nötigen Aufgaben sicher und schnell erledigt werden. Letzteres erfolgt oft automatisiert und dies meist in und mit Skripten. Wenn Sie also mal einen Administrator vor sich sehen, der seine tägliche Arbeit und sogar die Dokumentation seiner Systeme automatisiert hat, dann gehen Sie ruhig davon aus, daß Ihnen ein absoluter Profi gegenübersitzt.

Warum überhaupt Shellskripte?

Der große Vorteil von Shellskripten selbst ist es, daß sie in weiten Bereichen universell einsetzbar sind. Sie sind unabhängig von einer Betriebssystemversion oder sogar vom Betriebssystem selbst. Sie sind unabhängig davon ob ein Server in einer 32-Bit oder einer 64-Bit Umgebung läuft. Diese Unabhängigkeit ist mit Programmen einer Hochsprache schwer zu erreichen, unter UNIX eventuell mit ANSIC C Programmen, die auf shared libraries verzichten. Aber meist sind Shellskripte dann immer noch flexibler und sei es nur weil sie jeder schnell ansehen, debuggen und ggf. anpassen kann. Kornshellskripte werden beim einlesen übrigens kompiliert und laufen dann aus dem RAM. Sie werden bei der Ausführung nicht wieder und wieder eingelesen. Deshalb sind sie auch meist hinreichend schnell.

Wie schreibt man schnelle Shellskripte?

Geschwindigkeit ist das nächste Stichwort. Auch in Zeiten von 5GHz Prozessoren kann die Ausführungszeit eines Skriptes eine Rolle spielen. Und zwar immer dann, wenn ein Skript a) viele Aktionen nacheinander ausführt und/oder b) das Skript selbst oft aufgerufen wird. Dann kommt es darauf an, was das Skript genau erledigt.

Interne oder Externe Kommandos

Es ist immer von Vorteil wenn das Skript mit den Möglichkeiten der eigenen Shell auskommt, denn alles was zur Shell gehört ist bereits im Speicher geladen und muß nicht erst von Platte eingelesen werden. Der Vorteil wird größer mit der Häufigkeit der einzelnen Aktionen im Skript. Noch wichtiger wird die Frage internes Shellkommando oder externes Programm wenn es um Schleifen geht. Bei der Verarbeitung von Zeichenketten z.B. werden Shellkommandos oft mit cut, sed, awk oder anderen Programmen kombiniert. Für jeden einzelnen Aufruf externer Programme sind ein fork() und ein exec() nötig und je nach Zahl der Schleifendurchläufe kommt auch auf einem modernen Server eine spürbare Anzahl an Systemaufrufen dabei heraus. Solange eine Zeichenkettenbearbeitung aber z.B. mit Jokern möglich ist (z.B. das ab- bzw. ausschneiden von Zeichen aus einer einzelnen Zeichenkette) ist die Shellfunktion selbst dann schneller als das externe Programm wenn man mehrere einzelne Shellbefehle braucht um zum Ergebnis zu kommen. Wenn man dennoch externe Programme verwendet sollte man darauf achten, daß sie entweder ganz vorne im $PATH zu finden sind oder sie mit vollständigem Pfad aufrufen.

Externe Programme können jedoch dann im Vorteil sein wenn z.B. viele Eingaben aus anderen Quellen (z.B. einer Pipe) hereinkommen. Nicht gemeint sind übrigens reine sed oder awk Programme1, die für sich allein wieder sehr schnell sein können, sondern es geht wie schon oben gesagt um die Kombination von Shell und externem Programm. Denn wenn eine Zeile nicht komplett intern mit entweder z.B. sed oder awk bearbeitet werden kann, sondern diese selber noch andere Programme aufrufen oder aus anderen Programmen aufgerufen werden, dann ist auch hier eine reine Shellfunktion fast immer schneller. Und wer seine Systemcalls für die DB, das SAP o.ä. braucht, der wird zusehen, daß er keine Systemcalls in seinem Skript verschwendet.

Numerische Operationen

Sobald wir Zahlen in der Kornshell verarbeiten ist es außerdem von Vorteil, wenn sie alle im Skript je nach Zweck entweder als Ganzzahl (integer) oder als Gleitkommazahl (float) definiert werden. Wenn man das nicht tut, muß die ksh einen string in eine Zahl transformieren, die Berechnung durchführen und das Ergebnis wieder in einen String verwandeln.

Kommandozeilenvervollständigung mit Kornshell

Ein oft geäußerter Grund für die Verwendung der bash anstelle der ksh sind Komfortfunktionen wie Kommandozeilenvervollständigung oder Auswahlmenüs in der Kommandozeile "weil die ksh das ja nicht hat". Stimmt nicht. Selbstverständlich kann man diese Funktionen auch in der Kornshell nutzen. Man muß nur den entsprechenden Editor setzen. Am Beispiel von vi:

An diesem Thema wird gearbeitet...

Plattformübergreifende Shellprogrammierung

Wer von vorneherein Shellskripte schreiben möchte, die auf jedem *nix/*nux laufen sollen, der hält sich beim verwendeten Befehlssatz exakt an die POSIX kompatible UNIX standard shell .

Unterschiede zwischen Bash, Bourne und Kornshell

Ein paar Unterschiede zwischen den Shells finden sich in der folgenden Tabelle.

Unterschiede zwischen Bash-, Bourne- und Kornshell
Kornshell Bash Bourne
function function <name> {

Befehle

}

oder

<name>()

{

Befehle

}

function <name> {

Befehle

}

oder

<name>()

{

Befehle

}

<name>()

{

Befehle

}

trap
  • lokal in einer Funktion
  • wenn in main definiert für alle Funktionen  nutzbar, kann innerhalb einer Funktion überschrieben werden
global
echo shell builtin shell builtin
print shell builtin

AIX Shell Kommandos

Damit unter AIX auch Nicht-Kornshell Skripte funktionieren bringt das Betriebssystem eine Reihe von Kommandos mit, die in anderen Shells eingebaut sind. Der Preis für die Nutzung ist wie schon oben erwähnt jedoch eine längere Ausführungszeit.

(*) Das "echo" Kommando ist eine Ausnahme. Es existiert in AIX sowohl als separates Programm als auch in der Kornshell eingebaut. Bei der Nutzung von "echo" auf der Kommandozeile wird das separate Programm aufgerufen, in einem Skript jedoch (wenn man nicht auf die binäre Datei verweist) die in die ksh eingebaute Funktion. Auf der Kommandozeile ist deshalb "print" schneller als "echo", im Skript sind "print" und "echo" gleich schnell. Wer also Skripte schreibt, die in verschiedenen Shells funktionieren (sollen) verwendet dann in jedem Fall "echo"  anstelle von "print".

An diesem Thema wird gearbeitet...

Korn Shell für Windows - U/Win

http://www.research.att.com/software_tools

http://www2.research.att.com/sw/tools/uwin/

Literaturempfehlung: