Nächste Seite: Wozu ist Shellprogrammierung gut, Aufwärts: Einleitung Vorherige Seite: Was fehlt noch? Inhalt
Eine Shell ist unter Unix ein Kommandointerpreter3.2. Man tippt Kommandos ein (wie beispielsweise cp *.txt /tmp, ls /home/meier etc.) und die Shell versucht dann nach bestem Wissen und Gewissen das zu tun, was man mit dem Kommando gemeint hat.
Wenn man so arbeitet, dann nutzt man die Shell interaktiv, weil man jeweils ein Kommando eingibt, und hoffentlich sieht, was man damit angerichtet hat. Dann gibt man das nächste Kommando ein.
Daneben kann ein Unixrechner3.3 beziehungsweise eine darauf laufende Shell (wie in den meisten anderen Betriebssystemen auch) im Stapelbetrieb (zumindest hieß das früher so, neudeutsch: batch) arbeiten. Dazu schreibt man die Kommandos in eine Datei, und bringt dann eine Shell dazu, ihre Kommandos nicht von der Tastatur zu lesen, sondern aus der Datei (das entspricht einem Stapel Lochkarten, auf dem Karte für Karte die Befehle eingestanzt sind; daher die Bezeichnung Stapelbetrieb). Diese Datei (oder der Kartenstapel) ist dann ein Shellprogramm. Wem das Wort Shellprogramm zu lang ist, der kann auch Shellskript, Skript, shell script oder script dazu sagen.
Die Kommandos, die einem zur Verfügung stehen, kann man in interne und externe Kommandos unterteilen.
Interne Kommandos sind in die Shell fest eingebaut, externe Kommandos werden nach dem Aufruf erst nachgeladen (entweder als Binärprogramm, oder als Shellprogramm, das in der aktuellen Shell läuft, oder als Shellprogramm, für das erst noch eine weitere Shell nachgeladen werden muß).
Um die Sache nicht zu einfach zu machen, gibt es natürlich nicht eine Shell, sondern mehrere.
Die ursprüngliche Shell, die anfangs auf Unixrechnern als /bin/sh zu finden war, ist die sogenannte Bourne-Shell (nach ihrem Ziehvater Steve R. Bourne). Sie gilt nach wie vor als Standardshell unter Unix. Ihre Sprache ist wohl die am häufigsten verwendete Programmiersprache der Welt, da die neuere Kornshell und jetzt die aktuelle bash im wesentlichen Erweiterungen der Bourne-Shell sind.
Die C-Shell (/bin/csh) ist nicht kompatibel zur Bourne-Shell. Um effektiver zu arbeiten, sind früher viele Leute auf die csh umgestiegen. Da sie eben inkompatibel zur sh ist, wurden nicht allzuviele Skripte damit erstellt. Sie wurde weitgehend zur interaktiven Arbeit verwendet. Aus der csh ist die tcsh entstanden, die ebenfalls hauptsächlich interaktiv benutzt wird.
Eine direkte Erweiterung der sh ist die Korn-Shell (benannt nach ihrem Schöpfer David Korn). Sie bietet gute Erweiterungen, auch zum interaktiven Arbeiten, und ist weitgehend kompatibel zur sh. Leider unterliegt sie in ihrer ursprünglichen Version der generellen Unixlizenz, sie ist keine freie Software. Als Nachbau entstand die frei verfügbare pdksh (public domain ksh), die sich aber nicht allzu weit durchsetzen konnte. Sie wird inzwischen von der ebenfalls freien bash (Bourne again shell) verdrängt, die leistungsfähiger ist und ebenfalls weitgehend kompatibel zu sh und ksh.
Inzwischen schwören viele Leute auf einen neuen Trend: perl verdrängt in einigen Bereichen die sh-Skripte. perl ist erstaunlich schnell entstanden, und wird von vielen Programmierern als das einzig Wahre proklamiert. Von ideologischen Auswüchsen abgesehen, ist sie einerseits sehr leistungsfähig, da sie einen sehr mächtigen Sprachumfang hat, und ihre Syntax klar definiert ist (wenn auch nicht sehr verständlich). Andererseits muß man sich intensiv damit beschäftigen, um damit ein Bein auf den Boden zu bekommen. perl ist vollkommen inkompatibel zu allen anderen Skriptsprachen, und auch zu sich selbst, da inzwischen mehrere Versionen existieren, die sich gar nicht vertragen. Es ist halt eine sehr junge Sprache, die sich noch schnell weiterentwickelt.
Um die Sache jetzt doch wieder einfacher zu machen: In diesem Text wird es in erster Linie um die Sprache von sh und bash gehen.