Programmer's Toolbox (1): Einleitung und Grundlagen

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 fŸr 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 HinzufŸgen von eigenen externen Kommandos beliebig zu erweitern ohne sie im Kern ändern zu mŸssen. Außerdem ist es möglich die externen Shell-Kommandos außerhalb der Shell anzuwenden. Die EinfŸhrung 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 fŸr 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 eingefŸhrt. F†r dieses Thema sind vier Folgen vorgesehen.

#3. Vom Packen und VerschlŸsseln Im dritten Block geht es dann um das Packen und VerschlŸsseln von Dateien. Es wird gezeigt wie Dateien platzsparend abgelegt werden. Außerdem werden unterschiedliche VerschlŸsselungsarten eingefŸhrt, untersucht und programmiert. Die Anwendung ist hier vielfältig und reicht vom Paßwortschutz fŸr bestimmte Programme, bishin zur (fast) sicheren VerschlŸsselung 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, dŸrften die Kommandos auch mit einem beliebigen anderen C-Compiler fŸr 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.

Rund ums Dateisystem

Kommen wir nun zur Inhaltsangabe des ersten thematischen Blocks: Heute erfolgt eine EinfŸhrung grundlegender Begriffe. Es werden allgemeine Begriffe wie Gerät, Pfad und Kommando eingefŸhrt. 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):

Von Geräten, Pfaden und Verzeichnissen Doch damit genug vorausgeschaut, beginnen wir mit der Begriffsklärung und hier mit dem Begriff Gerät. In einer abstrakten Betrachtungsweise stellt sich ein Gerät als Eingabe- oder Ausgabemöglichkeit fŸr einen Computer dar. Reine Eingabegeräte sind etwa die Tastatur und die Maus. Ausgabegeräte sind Bildschirm und Drucker. Daneben existieren eine Reihe von Geräten die Eingabe- und Ausgabegeräte sein können, etwa die Floppy-Disk oder die Hard-Disk. Normalerweise werden diese Geräte genutzt um große, zeitweise nicht benötigte Datenmengen zwischenzuspeichern und fŸr spätere Anwendungen zur VerfŸgung zu haben. Die Ablage der Daten erfolgt dabei in Dateien. Im Gegensatz zu den reinen Eingabe- bzw. Ausgabegeräten benötigen Geräte mit Eingabe- und Ausgabefähigkeiten einen Speicher. Einen Speicher der mitunter ein Vielfaches der Kapazität des Hauptspeichers besitzt und damit eine große Anzahl von Dateien aufnehmen kann. Unter diesem Umstand ist es verständlich, daß eine bestimmte Organisationsform fŸr die Dateien gefunden werden muß, um einen gewissen Grad von †bersichtlichkeit zu erreichen. Der Begriff Dateisystem ist dabei nichts weiteres als eine andere Bezeichnung fŸr "Organisationsform fŸr Dateien". Das von ATARI fŸr den ST benutzte Dateisystem lehnt sich dabei an eine Organisationsform an, die bereits etwas betagt ist, nichtsdestotrotz aber bisher recht erfolgreich war: die XENIX-Struktur. Innerhalb von Betriebssystemen, die gemäß der XENIX-Struktur organisiert sind (UNIX, MS-DOS, TOS,...), erfolgt die Strukturierung von Dateien mit Hilfe von Verzeichnissen. Ein Gerät enthält hierbei genau ein sogenanntes Hauptverzeichnis. Das Hauptverzeichnis erlaubt den Eintrag von Dateien und Unterverzeichnissen. Auch Unterverzeichnisse können ihrerseits wiederum Verzeichnisse enthalten und sofort. Es ergibt sich die Möglichkeit einer hierarchischen Schachtelung von Verzeichnissen, womit wir bei Abb.1.1 sind.

center 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 fŸr den Dateinamen; ein Punkt; maximal drei Buchstaben fŸr 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 gewŸnschten 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. FŸr 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, fŸhrt 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 fŸhrenden Wurzelkennung ''. Allerdings sind relative Pfade meistens deutlich kŸrzer, 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 zurŸck!". 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. NatŸrlich 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 fŸr den Rechner. Damit ist "Kommando" an sich nichts weiter als eine andere Bezeichnung fŸr 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 durchgefŸhrt. 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.

center 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 darŸber 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 fŸhrenden '-' gekennzeichnet. Zusätzlich gilt, daß alle Optionen eines Kommandos vor dem Auftreten des ersten Argumentes angegeben sein mŸssen, 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 RŸckfragen 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. FŸr 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.

center

Zu sehen ist, daß die Umlenkung der Standardeingabe mit einem '<'-Zeichen vorgenommen wird. Entsprechendes gilt fŸr die Standardausgabe und das '>'-Zeichen. Das Beispiel wŸrde 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 unterstŸtzt, 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 fŸr die Standardkanäle durchgefŸhrt.

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" eingefŸhrt.

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 fŸr optionale Komponenten. Argument ist ein Platzhalter fŸr 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 ParameterŸbergabemechanismus 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 ParameterŸbergabemechanismus der erste String immer leer bleibt, nichtsdestotrotz in der Berechnung fŸr argc aber mitgezählt wird. Betrachten wir einen ECHOSIMP-Aufruf der folgenden Form:

ECHOSIMP -N Hallo Welt

Es ergeben sich folgende Zustände fŸr 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 fŸhren sie vor ihrer AusfŸhrung 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 AusfŸhrung des TTP-Dialoges im Desk-Top und dem Aufruf von Pexec. Wird Pexec nicht aus dem Desk-Top ausgefŸhrt, erfolgt damit auch keine Konvertierung! Auswirkungen dieser Tatsache bestehen z.B. darin, daß Kommandos eigenständig dafŸr 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.

Vorausschau

Ja, das wars dann auch schon fŸr heute. In der nächsten Folge der "Programmer's Toolbox" folgt die EinfŸhrung 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 - TschŸss bis zum nächsten Mal.

Listings zur Programmer's Toolbox (1)


Dirk Brockhaus
Aus: ST-Computer 06 / 1990, Seite

Links

Copyright-Bestimmungen: siehe Über diese Seite