Lieber Leser!
Eigentlich hat man sich ja daran gewöhnt, an die Maus, die Fenster und an alles was sonst noch zu einer grafischen Benutzeroberfläche wie der des ATARI ST gehört. Trotzdem, so manchmal juckt es mich doch in den Fingern, das Hacken, das Malträtieren von Tastaturen durch die manuelle Eingabe von Kommandozeilen.
Verstärkt wird dieses Jucken, wenn sich beispielsweise folgende Aufgabenstellung einstellt:
Sichere alle C-Sourcen aus Verzeichnis C:\XYZ\ auf Diskette!
Da hat man es nämlich wieder: Durch jahrelangen mehr oder weniger ungebrochenen Fortschritt in der Entwicklung der Mensch-Maschine-Kommunikation ist man nun gezwungen, seine Brille aus der Ecke hervorzukramen und das lästige Suchen von Dateien mit der Endung "C" beginnt. Hat man endlich fast alle derartigen Dateien beisammen, dann klickt die dumme Maus doch wieder an der falschen Stelle und die Suche beginnt erneut. Der Rest ist Legende. Dabei könnte es doch so einfach sein:
CP C:\XYZ\*.C A:\
Probleme der oben geschilderten Art haben mich auf die Idee zu dieser Artikelserie gebracht. Aus der Idee wurde Handlung und aus der Handlung wurde Software: Die Software, die Sie in den nächsten Folgen der ST Computer innerhalb dieser Serie abgedruckt finden. Es handelt sich dabei um eine textuelle Benutzeroberfläche. Damit ich im folgenden aber nicht immer "textuelle Benutzeroberfläche" sagen muß, nenne ich sie ab jetzt bei ihrem englischen Namen und der lautet "Shell". Die Shell besitzt einen kleinen Kern von eingebauten Kommandos und eine weitaus größere Anzahl von externen Kommandos (Kommandos die fr sich genommen eigenständige Programme darstellen). Diese Konzeption bietet eine Reihe von Vorteilen: Der erste Vorteil besteht darin, daß die Shell klein ist. Nachgeladen werden immer nur die gerade benötigten Kommandos. Weiterhin besteht die Möglichkeit die Shell durch Hinzufgen von eigenen externen Kommandos beliebig zu erweitern ohne sie im Kern ändern zu mssen. Außerdem ist es möglich die externen Shell-Kommandos außerhalb der Shell anzuwenden. Die Einfhrung und Programmierung der Kommandos geschieht dabei in insgesamt drei thematischen Blöcken:
#1. Rund ums Dateisystem Der erste Block umfaßt die Shell sowie einige Kommandos, die zur Dateiverwaltung benötigt werden (Ansehen von Verzeichnissen, Verschieben, Löschen und Kopieren von Dateien, etc.). Dabei werden grundlegende Begriffe rund um das Dateisystem erklärt und es erfolgt eine Vorstellung der fr das Thema wesentlichen Bestandteile des Betriebssystems. Weiterhin wird gezeigt wie Pipelining, EA-Umlenkung und Kommandoprozeduren mit und innerhalb der Shell realisiert werden können. Insgesamt werden zu dieser Thematik acht Folgen erscheinen.
#2. Text Der zweite thematische Block behandelt eine spezielle Dateiart: Text. Es werden Kommandos zum Ansehen, Sortieren und Durchsuchen von Text eingefhrt. Fr dieses Thema sind vier Folgen vorgesehen.
#3. Vom Packen und Verschlsseln Im dritten Block geht es dann um das Packen und Verschlsseln von Dateien. Es wird gezeigt wie Dateien platzsparend abgelegt werden. Außerdem werden unterschiedliche Verschlsselungsarten eingefhrt, untersucht und programmiert. Die Anwendung ist hier vielfältig und reicht vom Paßwortschutz fr bestimmte Programme, bishin zur (fast) sicheren Verschlsselung ganzer Dateien. Der dritte thematische Block wird voraussichtlich ebenfalls vier Folgen umfassen.
Die Kommandos innerhalb aller Artikel sind dabei angelehnt an entsprechende Kommandos unter dem Betriebssystem UNIX. Ihre Programmierung ist in C erfolgt. Verwendet wurde der Laser C Compiler. Da jedoch keine speziellen Aspekte dieses Programms benutzt werden, drften die Kommandos auch mit einem beliebigen anderen C-Compiler fr den ATARI ST kompilierbar sein. Voraussetzung dabei ist eine Betriebssystemschnittstelle (GEMDOS), sowie das Vorhandensein der UNIX kompatiblen Funktion der Sprache C.
An dieser einleitenden Stelle möchte ich nun noch einige Worte zum Titel der Serie sagen: Man kann sicherlich sagen, daß die in den einzelnen Kapiteln vorgestellten Kommandos so etwas wie "Programmwerkzeuge" darstellen. Eine Ansammlung von "Programmwerkzeugen" könnte man dann wohl auch als "Programmierers Werkzeugkasten" bezeichnen. Das war meine Ausgangsidee. Etwas "eingeenglischt" hört es sich nicht mehr ganz so bieder an, nämlich gerade "Programmer's Toolbox". ber die Verwendung von englischen Begriffen anstelle der deutschen kann man sicherlich streiten. Auch ich verwende im folgenden ein "gesundes Mischmasch" beider Sprachen. Mal ehrlich: "Cowboy" ziehen Sie doch wohl auch der Bezeichnung "Kuhhirte" vor. Mir geht es genauso. Der Rest des Titels - "Dateien" - weißt dann noch darauf hin, daß ausschließlich Programmwerkzeuge - "Tools" - behandelt werden, die sich mit der Bearbeitung von Dateien beschäftigen.
Kommen wir nun zur Inhaltsangabe des ersten thematischen Blocks: Heute erfolgt eine Einfhrung grundlegender Begriffe. Es werden allgemeine Begriffe wie Gerät, Pfad und Kommando eingefhrt. Ihre Bedeutung ist nicht auf den ATARI ST begrenzt, vielmehr finden sich die hier vorgestellten Strukturen auch in anderen Betriebssystemen. Als Beispiele sei hier nur auf MS-DOS und UNIX verwiesen. In der nächsten Folge geht es dann ins Innere des ST. Es werden die GEMDOS-Betriebssystemfunktionen des ATARI ST vorgestellt. Derartige Textstellen haben immer so etwas wie Nachschlagecharakter. Deshalb werde ich mich nicht auf die von mir benötigten Funktionen beschränken. Stattdessen werden alle Funktionen des GEMDOS kurz behandelt. Nachfolgend beginnt die eigentliche Programmierarbeit. Zunächst werden einige Hilfsfunktionen programmiert, die so sinnvolle Aufgaben, wie das Setzen der Systemzeit oder das Kopieren, das Bewegen und das Löschen von Dateien bewerkstelligen (3. Teil). Mit diesen Hilfsfunktionen ist es dann möglich einige Kommandos zu programmieren. Hierzu zählen die folgenden Kommandos (4. Teil):
CD - ndern des Arbeitsverzeichnisses
PWD - Ausgabe des Arbeitsverzeichnisses
DATE - Auslesen/Setzen des Systemdatums
TIME - Auslesen/Setzen der Systemzeit
DF - Auslastungsstatistik fr Dateisysteme Danach werden wir uns mit der Expansion von Argumenten beschäftigen (5. Teil) und Kommandos implementieren, die Argumentexpansion benutzen (6. und 7. Teil). Dies sind die folgenden Kommandos:
LS - Anzeigen von Dateiinformationen
CP - Dateien kopieren
MV - Dateien bewegen
RM - Löschen von Dateien
RMDIR - Löschen von Verzeichnissen
MKDIR - Erzeugen von Verzeichnissen
CHMOD - ndern des Dateizugriffsmodus
TOUCH - Aktualisierung der Modifikationszeit von Dateien Zum Abschluß des ersten Artikelblocks wird die Shell (Kommando SSH) programmiert (8. Teil). Es wird gezeigt, wie man korrekte Eingaben erkennt und wie Pipelining und Kommandoprozeduren realisiert werden.
Will man nämlich derartige hierarchische Schachtelungen in ihrer Gesamtheit darstellen, bietet sich die dort gewählte baumartige Darstellungsweise an. Die Wurzel des Baumes ist dabei das Hauptverzeichnis und wird mit dem Zeichen '' benannt. Unterverzeichnis- und Dateinamen sind mit gewissen Einschränkungen (maximal acht Buchstaben fr den Dateinamen; ein Punkt; maximal drei Buchstaben fr den Dateityp) frei wählbar und bilden die "Knoten" und die "Blätter" des Baumes. Die "ste" des Baumes stellen je nach Betrachtungsweise eine der beiden Relationen "ist Unterverzeichnis von" bzw. "ist Unterverzeichnis in" dar. Ein Pfad bis zu einer Datei oder einem Verzeichnis ist jeweils der Weg vom Hauptverzeichnis bis zu der gewnschten Datei bzw. dem Verzeichnis. Zur eindeutigen Identifizierung einer Datei innerhalb eines Dateisystems wird in Systemen mit XENIX-Struktur der Pfadname der Datei verwendet. Der Pfadname einer Datei ist die Aneinanderreihung aller Unterverzeichnisnamen beginnend vom Hauptverzeichnis bishin zur Datei. Die Unterverzeichnisnamen werden beim ATARI ST dabei mit dem Zeichen '' voneinander getrennt. Fr die Datei "KAP_1.DOC" innerhalb von Abb.1.1 gilt damit der Pfadname:
\USR\TOOLBOX\DOCUMENT\KAP.1\KAP_1.DOC
Da diese Pfadnamen bei stark geschachtelten Dateisystemen mitunter recht länglich werden, fhrt man den Begriff des Arbeitsverzeichnis bzw. des aktuellen Verzeichnis ein. Das Arbeitsverzeichnis ist unter allen Verzeichnissen des Dateisystems frei wählbar. Nach Wahl eines Arbeitsverzeichnisses können Zugriffe auf Dateien oder weitere Verzeichnisse relativ zum Arbeitsverzeichnis erfolgen. Relative Pfadnamen unterscheiden sich äußerlich kaum von gewöhnlichen (absoluten) Pfadnamen. Sie erkennt man lediglich am Fehlen der fhrenden Wurzelkennung ''. Allerdings sind relative Pfade meistens deutlich krzer, da bei ihnen nur der Pfad ab dem Arbeitsverzeichnis angegeben werden muß. Mit dem Arbeitsverzeichnis "\USR\TOOLBOX\DOCUMENT" könnte so etwa die Datei "KAP_1.DOC" in Abb.1.1 mit folgendem Pfad selektiert werden:
KAP.1\KAP_1.DOC
Auch Dateien außerhalb des Arbeitsverzeichnisses lassen sich relativ zum Arbeitsverzeichnis beschreiben. Will man etwa aus dem Arbeitsverzeichnis "\USR\DATEN.C" die Datei "KAP_1.DOC" selektieren, so geschieht dies mit folgendem Pfad:
..\TOOLBOX\DOCUMENT\KAP.1\KAP_1.DOC
Die Verwendung der beiden Punkte innerhalb der Pfadnamen bedeutet dabei soviel wie: "Gehe ein Verzeichnis im Dateisystem zurck!". Tatsächlich ist ".." ein Verzeichnis, das in jedem Unterverzeichnis "unsichtbar" vorhanden ist und das auf das jeweilige Vorgängerverzeichnis weißt. Damit ist es auch an den äußeren Enden eines Dateisystems bequem möglich, Dateien in unmittelbarer Nähe anzusprechen, ohne den absoluten Pfadnamen anzugeben. Natrlich kann man ".." auch in absoluten Pfaden verwenden, besonders sinnvoll ist das aber nicht:
\USR\..\USR\TOOLBOX\..\TOOLBOX\DOCUMENT\KAP.1\KAP_1.DOC
Ich kann mir nicht helfen, irgendwie sieht das sehr nach stottern aus.
#Von Kommandos, Optionen und Argumenten Weitere Grundbegriffe gruppieren sich um den Begriff des Kommandos:
Unter einem Kommando versteht man eine Handlungsanweisung fr den Rechner. Damit ist "Kommando" an sich nichts weiter als eine andere Bezeichnung fr den allgemeineren und geläufigeren Begriff des "Programms". In Abgrenzung zu allgemeinen Programmen wird der Begriff des Kommandos im folgenden jedoch mit einer eingeschränkten Bedeutung benutzt: Als Kommandos sollen nur diejenigen Programme bezeichnet werden, die auf die grafischen Möglichkeiten des ST verzichten. Dies sind die sogenannten TOS-Programme. Im ST Betriebssystem enden sie entweder auf "TOS" oder auf "TTP". Interessanter sind dabei die auf "TTP" endenden Programme, da sie dem Anwender die Möglichkeit geben dem Programm durch eine Kommandozeile Anweisungen zu erteilen (TOS Takes Parameter). Werden TTP-Programme aus dem Desk-Top gestartet, dann wird zur Eingabe der Kommandozeile ein Dialog durchgefhrt. Diese Kommandozeile wird beim direkten Aufruf von TTP-Programmen (also unter Umgehung des Desk-Top) dem Betriebssystemaufruf Pexec als (String-) Parameter mitgegeben. Innerhalb dieser Artikelserie soll nun eine dritte Möglichkeit realisiert werden: Die Eingabe von Kommandos als Text innerhalb einer Shell. Einen ersten Eindruck, wie dies auszusehen hat, möchte ich mit Abb.1.2 und dem zunächst noch hypothetischen Kommando LS vermitteln.
Hier dargestellt ist eine Kommandozeile, wie sie in der späteren Implementierung von unserer Shell verstanden werden soll. Die einzelnen Parameter der Kommandozeile werden dabei durch Leerzeichen vom Kommandonamen und voneinander getrennt. Weiterhin werden zwei Arten von Parametern unterschieden: Optionen und Argumente. Ein Parameter wird als Option bezeichnet, wenn er einem Kommando Auskunft darber gibt, WIE es zu arbeiten hat. Dagegen gilt ein Parameter als Argument, wenn er dem Kommando angibt WAS zu bearbeiten ist. blicherweise sind Optionen mit einem fhrenden '-' gekennzeichnet. Zusätzlich gilt, daß alle Optionen eines Kommandos vor dem Auftreten des ersten Argumentes angegeben sein mssen, ansonsten werden sie nicht mehr als Optionen erkannt, sondern als Argumente behandelt.
Anmerkung: Bitte beachten Sie, daß die Differenzierung zwischen Optionen und Argumenten nur auf einer Konvention beruht. Der nachfolgend beschriebene bergabemechanismus behandelt beide Parameterarten gleich.
Mit der Einschränkung von Kommandos auf Text als einziges Mittel zur Ein- und Ausgabe, vereinfachen sich die Wechselwirkungen zwischen Kommandos und ihrer Umgebung drastisch. Lediglich Rckfragen zur Anforderung von Steuerinformationen und Ergebnisausgaben sind neben der eigentlichen Wirkung von Kommandos möglich. Der Datenkanal aus dem ein Kommando Steuerinformationen ließt, heißt dabei Standardeingabekanal. Umgekehrt heißt der Datenkanal ber den Steuerinformationen angefordert werden und der die Ergebnisausgabe ermöglicht Standardausgabekanal. Fr beide Kanäle ist die Konsole voreingestellt, d.h. Ein- und Ausgaben geschehen interaktiv mit Bildschirm und Tastatur. Zur Flexibilisierung von Programmabläufen sind jedoch Umlenkungen beider Kanäle erlaubt, um z.B. den wiederholten Ablauf eines Kommandos mit gleichen Steuerinformationen zu erlauben. Abb.1.3 zeigt dazu ein Beispiel.
Zu sehen ist, daß die Umlenkung der Standardeingabe mit einem '<'-Zeichen vorgenommen wird. Entsprechendes gilt fr die Standardausgabe und das '>'-Zeichen. Das Beispiel wrde etwa die Standardeingabe des (auch noch hypothetischen) Kommandos CAT aus der Datei "DATEI3" entnehmen. Die Standardausgabe erfolgt in die Datei "DATEISUM".
Anmerkung: Das '-' ist in Abb.1.3 keine Option, sondern kennzeichnet die Stelle an der die Standardeingabe in die Ausgabe des Kommandos CAT bernommen wird. CAT wird erst im zweiten Block der "Programmer's Toolbox" realisiert.
Beide Umlenkungsarten werden direkt durch TOS untersttzt, d.h. wenn beim Aufruf eines TTP-Programms (aus dem Desk-Top oder mit Pexec) eine Kommandozeile mit Umlenkungen angegeben wird, dann wird das Programm mit den entsprechenden Werten fr die Standardkanäle durchgefhrt.
Soviel zunächst zu der Sicht aus dem Betriebssystems auf Kommandos und ihre Parameter. Bevor nun gezeigt wird, wie die bergebenen Parameter dem Kommando zugänglich gemacht werden, möchte ich kurz Listing 1.1 vorstellen. Es zeigt nicht viel: Einige wenige Konventionen, die ich im weiteren Ablauf verwenden möchte, werden hier in Form der Header-Datei "LOCAL.H" eingefhrt.
Das erste "echte" Listing bezieht sich dann aber bereits auf das Thema: Listing 1.2 zeigt eine "abgespeckte" Version des eigentlich erst im zweiten Block vorkommenden Kommandos ECHO. Diese "abgespeckte" Version erhält die Bezeichnung ECHOSIMP und macht nichts anderes, als die ihm bergebenen Argumente auf den Standardausgabekanal zu schreiben. Abschließend wird das ganze dann noch mit einem Zeilenvorschub versehen. Die einzige erlaubte Option besteht dabei darin, den Zeilenvorschub abzustellen (Option "-N"). In einer gebräuchlichen Schreibweise läßt sich die Parametrisierung von ECHOSIMP folgendermassen beschreiben:
ECHOSIMP [ -N ] [ Argument... ]
Die eckigen Klammern stehen dabei fr optionale Komponenten. Argument ist ein Platzhalter fr ein beliebiges Argument und die Induktionspunkte besagen, daß eine beliebige Anzahl von Argumenten erlaubt sind. Insbesondere ist es damit erlaubt, ECHOSIMP ohne Argumente aufzurufen.
Der Zweck dieser vorgezogenen Variante des Kommandos ECHO ist die Demonstration des Parameterbergabemechanismus anhand eines einfachen Beispiels. Wenn wir uns nun der Implementierung von ECHOSIMP zuwenden, dann ist hier zunächst die Funktion main von Interesse. Die beim Programmaufruf bergebenen Parameter tauchen hier nämlich als Funktionsparameter der Hauptfunktion main wieder auf. Der erste Funktionsparameter von main (argc) gibt dabei an, wieviele Parameter insgesamt bergeben werden. Der zweite Parameter (argv) weißt auf ein Feld von Strings, das die aktuellen Werte der Parameter enthält. Dabei ist zu beachten, daß in der Laser C Implementierung des Parameterbergabemechanismus der erste String immer leer bleibt, nichtsdestotrotz in der Berechnung fr argc aber mitgezählt wird. Betrachten wir einen ECHOSIMP-Aufruf der folgenden Form:
ECHOSIMP -N Hallo Welt
Es ergeben sich folgende Zustände fr die Parameter von main:
argc : 4 argv[0] : "" argv[1] : "-N" argv[2] : "Hallo" argv[3] : "Welt"
Die das Kommando realisierende Funktion echosimp zeigt nun, wie die Parameter interpretiert werden. Zunächst wird hier die Option abgefragt und gegebenenfalls ein entsprechender Merker gesetzt (newline), dann werden die brigen Parameter als Argumente ausgegeben. Zum Abschluß wird noch, in Abhängigkeit vom Wert des Merkers, ein Zeilenvorschub vorgenommen.
An dieser Stelle möchte ich auf eine Eigenheiten des ST-Betriebssystems hinweisen, da sie auch Eingang in die Implementierung meiner Programme findet. Im Gegensatz beispielsweise zu UNIX gehört TOS zu den Betriebssystemen, die nicht zwischen Klein- und Großschreibung differenzieren. In der Praxis sieht dies so aus, daß alle Betriebssystemaufrufe ausschließlich mit Großbuchstaben arbeiten. Entsprechend fhren sie vor ihrer Ausfhrung zunächst eine Konvertierung aller Kleinbuchstaben in Großbuchstaben durch. Ausnahmen bestätigen die Regel und eine der Ausnahmen bei der Stringkonvertierung ist gerade die Funktion Pexec. Im Gegensatz zu anderen Betriebssystemaufrufen wird die Pexec bergebene Kommandozeile nicht konvertiert. Die Konvertierung erfolgt hier bereits zuvor, nämlich zwischen der Ausfhrung des TTP-Dialoges im Desk-Top und dem Aufruf von Pexec. Wird Pexec nicht aus dem Desk-Top ausgefhrt, erfolgt damit auch keine Konvertierung! Auswirkungen dieser Tatsache bestehen z.B. darin, daß Kommandos eigenständig dafr zu sorgen haben, daß Kleinbuchstaben in Parametern richtig interpretiert werden. Auf der anderen Seite ist ein Kommando wie ECHO (oder ECHOSIMP) nicht darauf eingeschränkt ausschließlich großgeschriebene Texte auszugeben.
Ja, das wars dann auch schon fr heute. In der nächsten Folge der "Programmer's Toolbox" folgt die Einfhrung der GEMDOS-Betriebssystemfunktionen. Erst hatte ich vor, nur die Funktionen herauszupicken, die innerhalb der Serie benötigt werden. Da dann aber doch die meisten Funktionen betroffen gewesen wären, denke ich mir, daß es nicht schaden kann, ein komplettes Kurz-Reference des GEMDOS anzugeben. Wie Sie feststellen werden, ist das nicht so umfangreich, wie man denkt. In diesem Sinne - Tschss bis zum nächsten Mal.
Listings zur Programmer's Toolbox (1)