PKS-Shell: Ein Schritt in Richtung UNIX

Auch wenn es mancher Atari-Besitzer vielleicht nur ungern zugibt: Es gibt wichtigere Betriebssysteme als das TOS des ST. Oder besser gesagt: Durch ihre Verbreitung haben manche Systeme eine deutlich größere Bedeutung erlangt als TOS. Hierzu zählen in erster Linie MS-DOS und UNIX.

Kompatibilität ist Trumpf

Jedenfalls für IBM-kompatible PCs, die unter MS-DOS arbeiten. Dennoch dürfte MS-DOS trotz seiner weiten Verbreitung wohl kaum das System der Zukunft darstellen, da es aufgrund der Kompatibilität zu den ersten PC-Generationen nicht in der Lage ist, die Leistungsfähigkeit neuerer Rechner sinnvoll zu nutzen. Besonders die Verwaltung heute durchaus üblicher Hauptspeicherkapazitäten von mehr als 1 MB bereitet unter MS-DOS Probleme. Als vor knapp 10 Jahren die ersten IBM-PCs auf den Markt kamen, waren solche Kapazitäten noch undenkbar. Die grafische Oberfläche MS-WINDOWS dürfte für IBM-kompatible Rechner einen Ausweg aus dem Speicherplatz-Dilemma darstellen, aber hier bedarf es zunächst einer Anpassung der Software an die erweiterten Möglichkeiten unter WINDOWS.

System der ersten Stunde

Bleibt also UNIX. Dieses System wurde bereits Anfang der 70er Jahre geboren. Wiege von UNIX waren die Bell Laboratories, die dem amerikanischen Kommunikationskonzern AT&T (American Telephone and Telegraph) angegliedert sind. UNIX sollte den dort beschäftigten Systemprogrammierern eine neue, brauchbare Programmierumgebung zur Verfügung stellen.

Die ersten UNIX-Versionen gehen auf K. Thompson, D. Ritchie und B.W. Kernighan zurück. Die beiden letzteren dürften jedem C-Programmierer ein Begriff sein, wurde diese Programmiersprache doch von Kernighan und Ritchie entwickelt. Dieser Umstand hatte auch einen entscheidenden Einfluß auf die Entwicklung von UNIX: Nachdem die Urversion dieses Systems noch in Assembler geschrieben war, wurden im Laufe der Zeit mehr als 90% des gesamten UNIX-Systems in C codiert.

Ursprünglich war UNIX für den Einsatz auf Großrechnern gedacht. Nachdem die Rechenleistung und Speicherkapazität kleinerer Computer jedoch ständig weiter zunahmen, waren Anfang der 80er Jahre die ersten UNIX-Versionen für Mikrocomputer erhältlich. Auch Atari wird demnächst in den UNIX-Markt einsteigen: Auf der kommenden CeBit (13.3. bis 20.3.91) soll eine UNIX-Version für den Atari TT vorgestellt werden.

UNIX forever

Es mag zunächst seltsam anmuten, daß ein System, das schon ca. 20 Jahre auf dem Buckel hat, in Zukunft weiter an Bedeutung gewinnen wird. Eigentlich würde man auf dem schnei lebigen Computermarkt eher das Gegenteil erwarten.

Das Erfolgsgeheimnis von UNIX liegt in erster Linie in der Konzeption des Systems. Der UNIX-Systemkern selber ist recht kompakt. Die meisten Funktionen werden durch externe Dienstprogramme zur Verfügung gestellt. Durch die Verknüpfung der Fähigkeiten dieser Programme können unter UNIX viele Aufgaben sehr flexibel gelöst werden. Man kann durchaus davon sprechen, daß UNIX selbst vom Anwender programmiert werden kann. Dies geschieht ähnlich, wie es beispielsweise unter MS-DOS mit Hilfe von Batch-Dateien (Stapeldateien, Kommandodateien) möglich ist.

Da ein großer Teil des UNIX-Systems in C geschrieben wurde, sind Portierungen auf neue Rechner relativ unproblematisch zu bewerkstelligen. C-Programme sindim Gegensatz zu anderen Programmiersprachen vergleichsweise leicht auf neue Rechnersysteme übertragbar. Lediglich ein kleiner rechnerspezifischer Teil des UNIX-Systems muß an die neuen Gegebenheiten angepaßt werden.

Interessanterweise sind die Quelltexte des UNIX-Systemkerns Public Domain. Wenn man für ein UNIX-System dennoch einiges an Geld hinlegen muß, so zahlt man in erster Linie für die Anpassung an den eigenen Rechner und für die je nach Lieferumfang mehr oder weniger große Zahl an Dienstprogrammen.

Original und Fälschung

Die Lizenz für UNIX besitzt weiterhin AT&T, was diverse andere Firmen nicht daran gehindert hat, eigene UNIX-Ableger mit klangvollen Namen wie XENIX (Microsoft) oder SINIX (Siemens) zu entwickeln. Diese neuen UNIX-Derivate sind zum eigentlichen UNIX nicht immer ganz kompatibel. Inzwischen haben sich jedoch die wichtigsten UNIX-Vertreiber darauf geeinigt, Maßnahmen zur Standardisierung der unterschiedlichen UNIX-Abkömmlinge voranzutreiben. So gibt es seit 1985 im wesentlichen noch drei wichtige UNIX-Richtlinien, die weiter aneinander angeglichen werden sollen:

• X/OPEN Portability Guide, diverse Hersteller
• S VID (System V Interface Definition), AT&T
• POSIX (Portable Operating System for Computer Environments), diverse Hersteller

Die UNIX-Version V.4, die auch für den Atari TT ins Haus steht, stellt einen wichtigen Schritt im Hinblick auf diese Standardisierung dar.

Die PKS-Shell

Nun aber zurück zum ST. "PKS-Shell" -dies klingt im Gegensatz zu den eben angesprochenen Systemen gar* nicht mehr nach UNIX, aber der Name täuscht. Soweit es realisierbar und sinnvoll ist, soll es mit diesem Programmpaket möglich sein, auch auf dem Atari ST und TT die Vorteile von UNIX unter TOS zu nutzen. Klar, daß typische UNIX-Eigenschaften wie echtes Multitasking und Multiuser-Betrieb für den Atari nicht in Frage kommen. Hier setzt leider das eigentliche Betriebssystem, das TOS, die Grenzen. Aber um UNIX kennenzulernen und Erfahrungen im Umgang mit UNIX-ähnlichen Betriebssystemen zu sammeln, ist das zunächst einmal nebensächlich.

Der erste Kontakt

Nachdem es bei GEM-unterstützten Programmen nicht unüblich ist, die Programmbeschreibung anfangs links liegen zu lassen (dank Menüleiste und Dialogboxen kommt man ja meist auch so zurecht), ist das Studium des Handbuchs der PKS-Shell unbedingt zu empfehlen. Dies gilt vor allen Dingen dann, wenn man selber noch keine UNIX-Erfahrung besitzt.

Das erste UNIX-Feeling kommt spätestens dann auf, wenn man einen Blick auf den Inhalt der Programmdiskette wirft. Hier finden sich nämlich nahezu beliebig viele Dateien, bei denen es sich in erster Linie um die externen UNIX-Dienstprogramme und Hilfsdateien handelt. Da das UNIX-Konzept darauf beruht, daß die meisten Befehle nicht zum eigentlichen Systemkern gehören, werden solche externen Befehle in Form von Programmdateien bei Bedarf geladen und ausgeführt. Wer nun vermutet, daß aufgrund dieses Prinzips aus Geschwindigkeitsgründen I eine Festplatte empfehlenswert ist, hat ins I Schwarze getroffen. Außerdem werden von UNIX des öfteren temporäre Dateien erzeugt, die zugunsten einer vernünftigen Arbeitsgeschwindigkeit nicht gerade auf einer Diskette abgelegt werden sollten. Ist keine Festplatte vorhanden, kann man sich zur Not auch mit einer RAM-Disk für diese Daten behelfen. Leider befindet sich keine RAM-Disk im Lieferumfang der PKS-Shell, aber auf dem Public Domain-Sektor gibt es ja genug Programme dieser Art.

alias
chdir
dirs
echo
errno
eval
exec
exit
export
expr
find
history
keypressed
limits
open

popdir
printf
pushdir
read
readhist
readonly
scrapdir
shift
shinfo
sleep
stty [echoe switch raw onlcr]
tee
test
trap
type
unset

args, banner, cal, chartab, chmod, cmp, comm, cp, cpio, ctags, cut, cw, date, dd, df, diff, du, eval, file, flop, getopt, grep, head, ls, make, memfind, mkdir, more, nm, od, paste, printhex, prof, rm, sed, showcore, sort, strings, strip, tail, touch, tr, version, wait, wc, what.

Shellfiles

aliases, backup, basename, clear, dircmp, dirname, install, man, shar

Sprachelemente

for..; do .. done
until.. ; do .. done
while .. ; do .. done
select... in ...; do ... done
case ... in ;... ; esac
if..; then ...; [elif...] [eise ...]fi
break
continue
return

Variable der Shell

CDPATH, COLS, DRIVES, ESCAPE, HOME, l FS, LINES, PATH, PS1, PS2, PS3, REPLY, SCAN_CODE, SHELL, SUFFIX, TMPDIR,

Ausgabe-Einheiten

aux:
con:
prn:

Wo die UNIX-Programmdateien sowie eventuelle temporäre Dateien abgelegt werden sollen, kann im Verlauf der Installation der PKS-Shell vom Anwender angegeben werden. Die Installation ist übrigens dank der ausführlichen Beschreibung trotz des aufwendigen Lieferumfangs leicht durchzuführen. In der mir vorliegenden neuen Version V 1.02 der Shell wurden jedoch einige Hilfsdateien nicht korrekt installiert. Hier gab es bei der Version 1.01 keine Fehler. (Möglich, daß Ermüdungserscheinungen der Autoren für dieses Problem verantwortlich sind. Wenn man der Erstellungszeit der Dateien Glauben schenkt, so wurden diese nämlich um 3 Uhr nachts zusammengestellt.)

Handbuch überflüssig

Da die PKS-Shell aus einer ganzen Reihe von eingebauten Befehlen und externen Dienstprogrammen besteht (Bild 1), ist es eine wichtige Aufgabe des Handbuchs, diese Befehle vorzustellen und Beispiele zu deren Nutzung zu geben. Dennoch hätte man sich das Handbuch für die PKS-Shell in diesem Punkt fast sparen können - nicht weil es unbrauchbar wäre, sondern weil man sich mit Hilfe des UNIX-kompatiblen man-Befehls ausführliche Erklärungen zu allen Funktionen der Shell auf dem Bildschirm anzeigen lassen kann. Ein Blick ins Handbuch erübrigt sich somit in vielen Fällen.

I want more

Wo wir gerade bei der Bildschirmausgabe sind: Hierzu steht unter UNIX der Befehl more zur Verfügung. Wie bei einigen anderen Dienstprogrammen wurden die Standardbefehle von UNIX bei der PKS-Shell um neue Eigenschaften erweitert. Das more-Kommando ist hierfür ein gutes Beispiel. So geschieht die Bildschirmausgabe von more auf einem gesonderten Bildschirm, und es ist mit Hilfe diverser Tasten möglich, den Text beispielsweise vor- und zurückzuscrollen.

Sehr praktisch ist es, daß more das WORDPLUS-Dateiformat sowie diverse Bildformate erkennt und solche Dateien im korrekten Anzeigeformat auf dem Bildschirm darstellt. Ruft man more also mit dem Namen einer IMG-Grafikdatei als Parameter auf, wird die Grafik auf dem Bildschirm angezeigt. Bei WORDPLUS-Dateien erfolgt die Ausgabe des Textes mit Schriftattributen. Bilder, die in Textdateien eingebunden wurden, finden jedoch bei der Ausgabe keine Berücksichtigung.

Bildateien können von more leider nur auf einem Monochrombildschirm, nicht jedoch in den Farbauflösungen angezeigt werden.

Muttersprache C

UNIX ist zum überwiegenden Teil in C programmiert. Diese Tatsache macht es für den C-Programmierer besonders einfach, Programme zu schreiben, die unter UNIX laufen sollen. Die PKS-Shell stellt einige externe Befehle zur Verfügung, die für den C-Programmierer sehr interessant sein dürften. (Eine Anpassung der Shell an die wichtigsten C-Compiler für den ST sowie an ST PASCAL+ wird übrigens vom Installationsprogramm automatisch durchgeführt.)

So ist es z.B. möglich, mit dem ctags-Kommando Verweislisten für C-Quell-texte erstellen zu lassen. Die erzeugten Dateien enthalten alle Funktionsdeklarationen und auf Wunsch auch Typvereinbarungen.

Werden die von ctags gelieferten Daten anschließend mit mkproto bearbeitet, erhält man eine Datei, in der Funktionsprototypen (gemäß ANSI-Standard) zu allen neu deklarierten C-Funktionen aufgeführt sind. Dies erleichtert die Anpassung älterer C-Quellen an neuere C-Compiler wie TURBO C.

Striptease

Neben C-spezifischen Dienstprogrammen bietet die PKS-Shell auch einige Funktionen, die für andere Programmiersprachen geeignet sind. strip ermöglicht es, die Symboltabelle eines Programms nachträglich aus der Programmdatei zu entfernen. Dies dürfte bei Programmen, die man selber geschrieben hat, zwar kaum notwendig sein, aber ab und zu stößt man auf fremde Programme, die aufgrund einer Symboltabelle unnötig lang sind. Ein prominentes Beispiel stellt der Debugger SID dar.

Ob ein Programm überhaupt eine Symboltabelle besitzt, läßt sich durch das Dienstprogramm size feststellen. Man erhält so auch Angaben über die Länge der einzelnen Programmsegmente (TEXT, DATA und BSS).

nm stellt ein weiteres Kommando dar, das mit Symbolen arbeitet. Interessiert man sich dafür, welche Symbole in einer Objekt- oder Programmdatei definiert sind, und in welchem Programmsegment diese Definition erfolgt, so liefert nm diese Angaben. Unterstützt wird momentan leider nur das Objektformat von Digital Research, das maximal acht Buchstaben pro Symbol erlaubt und deshalb zunehmend durch neue Formate ersetzt wird. Wünschenswert wäre eine Unterstützung zumindest der wichtigsten neuen Symbolformate wie z.B. des erweiterten Formats von TURBO C.

Kanalisierung

Wie es sich für eine ordentliche Shell gehört, bietet auch die PKS-Shell die Möglichkeit, Ein- und Ausgabekanäle nahezu beliebig umzudefinieren. So können Ausgaben, die eigentlich für den Bildschirm gedacht sind, in eine Datei oder auf den Drucker umgelenkt werden. Benötigt ein Programm umfangreiche Tastatureingaben, lassen sich diese Daten auch aus einer Datei einlesen. Aber Vorsicht: Die Umlenkung von Ein- und Ausgabekanälen ist in der Regel nur bei TOS-Programmen, nicht aber bei GEM-unterstützten Anwendungen möglich. Außerdem arbeitet die Umlenkung von Ein- und Ausgaben erst ab TOS 1.4 halbwegs fehlerfrei. Die alten TOS-Versionen wiesen hier Tücken auf.

Ein weiterer Teil der Dienstprogramme beschäftigt sich mit der Manipulation und Auswertung von Daten. Bei Bedarf sind auch statistische Aussagen über eine Textdatei erhältlich, wenn diese durch Kommandos wie grep oder wc unter die Lupe genommen wird.

Pfeifen - auch für Nichtraucher

Eine nützliche Eigenschaft von an UNIX angelehnten Shells ist die Realisierung sogenannter Pipes. Hierbei handelt es sich um Datenpuffer, die eine Verbindung zwischen mehreren Kommandos herstellen. Sehen wir uns als Beispiel die folgende Kommandozeile an:

ls -l | grep "Dez 1990" | wc -l

Das Kommando ls -l gibt zunächst das Directory des aktuellen Laufwerks inklusive Angaben über die Erstellungszeit der einzelnen Dateien aus. Die Ausgabe von Is erfolgt nun aber nicht auf dem Bildschirm, sondern wird über eine Pipe (hierfür steht das Zeichen "l") an den grep-Befehl weitergegeben, grep extrahiert aus den von ls gelieferten Daten alle Zeilen, in denen die Angabe "Dez 1990" enthalten ist. Das Ergebnis wird an wc weitergegeben, das die Zahl dieser Zeilen zählt und anschließend auf dem Bildschirm ausgibt. Die obige Kommandozeile zählt somit alle Dateien, die im Dezember 1990 erstellt wurden.

Die Verwendung von Pipes hat in diesem Beispiel dafür gesorgt, daß die Ausgaben der einzelnen Befehle an das jeweils folgende Kommando weitergeleitet wurden und nicht einfach nur auf dem Bildschirm erschienen sind. Es bleibt anzumerken, daß es sich bei den von der PKS-Shell unterstützten Pipes um temporäre Dateien handelt, die alle Ausgaben eines Kommandos aufnehmen und als Eingaben für den nächsten Befehl zur Verfügung stellen. In echten Multitasking-Systemen sind solche Pipes anders realisiert, da bei ihnen mehrere Befehle bzw. Programme gleichzeitig ablaufen können. Dies läßt das TOS des ST jedoch nicht zu. Eine sehr nützliche Nutzung von Pipes wäre die Kombination der Kommandos ctags und mkproto. So könnten für einem C-Quelltext direkt Funktionsprototypen erstellt werden. Leider führten Experimente zu Fehlern, ctags stürzte bei manchen Parametereingaben ab; beim Versuch, die Ausgaben von ctags über eine Pipe an mkproto weiterzuleiten, hängte sich das Dienstprogramm beim Schreiben der Prototypdatei auf oder meldete ohne ersichtlichen Grund einen Ausgabefehler.

Ein Blick auf die Uhr

Eine besonders interessante Eigenschaft der PKS-Shell ist die Option, Laufzeitmessungen durchzuführen. Gerade dann, wenn es um die Programmierung zeitkritischer Routinen geht, benötigt man genaue Informationen über die Ausführungszeit eines Programms. Zwar kann man längere Operationen mit einer Stoppuhr messen, aber im Computerzeitalter sollte es bessere Möglichkeiten geben. Leider erlauben es nur wenige Compiler, die Messung von Laufzeiten einzelner Unterprogramme durchzuführen. Mit der PKS-Shell ist es möglich, die Ausführungszeit eines kompletten Programms zu messen. Man erhält so nach dem Programmende automatisch eine Angabe über die seit dem Start verflossene Zeit. Auch die Zeitmessung einzelner Unterprogramme wird mit dem prof-Kommando unterstützt. Leider ist dieses nur unzureichend beschrieben und in den mittels man einsehbaren Handbuchdateien überhaupt nicht aufgeführt.

Konfiguration

Die Umgebung der PKS-Shell läßt sich leicht an die eigenen Bedürfnisse anpassen, Hierzu existieren unter anderem die sogenannten Shell-Flags. Diese Flags erlauben es, das Verhalten der Shell im Fehlerfall zu bestimmen, und bieten die Möglichkeit, Einfluß auf die Parameterübergabe bei Ein- und Ausgabeoperationen zu nehmen.

Alle Voreinstellungen können in einer sogenannten Profile-Datei abgelegt werden. Diese Datei wird bei jedem Start der Shell ausgewertet, und die in ihr enthaltenen Befehle werden ausgeführt. Auch beim Verlassen der Shell besteht die Möglichkeit, eine spezielle Datei ausführen zu lassen. So können wichtige Einstellungen automatisch beim Programmende gesichert werden.

Unabhängigkeitsbewegung

Nein, es wird nun nicht politisch. Unabhängig sind lediglich die Dienstprogramme der PKS-Shell vom eigentlichen Shell-Programm. Im Klartext: Bei den externen Befehlen der Shell handelt es sich meist um Programme des Typs TTP (TOS Takes Parameters). Es ist also möglich, diese Programme nicht nur aus der PKS-Shell heraus, sondern auch direkt über das Desktop zu starten. Durch geeignete Manipulation der Desktop-Info kann man so das MORE-Dienstprogramm als universelles Ausgabeprogramm für unterschiedliche Dateitypen einsetzen. Wie man dazu vorgehen muß, ist im Handbuch zur PKS-Shell erklärt.

Auch innerhalb von eigenen Programmen kann man die Befehle der PKS-Shell nutzen, sofern diese beim Programmstart aktiv war.

Die Theorie hierzu: Eine Shell richtet an der Adresse der Systemvariablen _shell_p einen Zeiger auf ihren Parser ein, der die Shell-Kommandos auswertet. Springt man diese Adresse an und liegt der Pointer auf eine für die Shell gedachte Kommandozeile auf dem Stack, wird diese bewertet, und die Kommandos werden so ausgeführt, als ob man sie per Hand eingetippt hätte.

Dieses Verfahren wird auch von der PKS-Shell unterstützt. Das Handbuch enthält leider nur sehr spärliche Angaben zur Übergabe von Kommandozeilen mittels _shell_p, womit wir bei der Programmbeschreibung angelangt wären.

Die Dokumentation

Das Handbuch der PKS-Shell hat einen Umfang von ca. 180 Seiten und ist in mehrere Abschnitte gegliedert. Neben dem Hauptteil, der sich mit dem Leistungsum-fang der einzelnen Befehle und Dienstprogramme beschäftigt, findet man auch einige allgemeine Bemerkungen zum UNIX-Konzept.

Besonders hervorzuheben ist die Beschreibung eines mitgelieferten Shell-Programms, das ein Backup von Dateien erlaubt. Hier wird ausführlich erklärt, wie man aus den Befehlen und Dienstprogrammen der PKS-Shell eine komplexe Anwendung zusammenstellen kann.

Wer sich zu den fortgeschrittenen Computer-Anwendern zählt, dürfte mit dem Handbuch zur Shell gut zurechtkommen, wenn auch an einigen Stellen ausführlichere Erklärungen angebracht wären. Für den Anfänger in Sachen Shell sind Verständnisschwierigkeiten wohl nicht zu vermeiden. Schließlich ist mir hier und da aufgefallen, daß manche Befehlsoptionen fehlerhaft erklärt sind oder vertauscht wurden, was zu Verwirrungen führen kann. Um einen tieferen Einblick in UNIX zu bekommen, reicht die Programmbeschreibung zur PKS-Shell verständlicherweise nicht aus, hier sollte man zu zusätzlicher Literatur greifen [1],[2]. Auch die Serie "Programmer's Toolbox-Dateien" in der ST-Computer enthält viele Informationen, die in den Umgang mit UNIX-ähnlichen Systemen einführen.

Zum guten Schluß

Die PKS-Shell ist nicht nur eine neue Shell für Atari ST und TT, sondern soll auch auf einen Kontakt mit "echten" UNIX-Systemen vorbereiten. Da ich mich als NichtInformatiker ursprünglich kaum mit UNIX beschäftigt hatte, hat mir die Arbeit mit der PKS-Shell einiges gebracht. Inzwischen arbeite ich auch ab und zu an Rechnern, die unter UNIX laufen und profitiere dabei von der UNIX-Erfahrung, die ich durch die PKS-Shell gesammelt habe.

Für UNIX-Interessierte, Programmierer (speziell in C) und diejenigen, die das Arbeiten mit Shells dem Arbeiten mit der Maus vorziehen, ist die PKS-Shell ein Schritt in die richtige Richtung. Einzeln ist die Shell für 168 DM erhältlich, in Kombination mit dem Texteditor PKS-Edit (getestet in der ST-Computer 12/90) ist man mit 248 DM dabei.

US