SPACE 2

home *** CD-ROM | disk | FTP | other *** search

/ SPACE 2 / SPACE - Library 2 - Volume 1.iso / program / 590 / doc / okami.doc < prev next >

Wrap

Text File | 1992-01-06 | 72.9 KB | 1,780 lines

=============================================== @(#) OKAMI SHELL VERSION 1.4 - BENUTZERANLEITUNG =============================================== Stand: 13.12.91 BITTE ERST DIE DATEI README LESEN! ---------------------------------------------------------------------------- EINFÜHRUNG Die Okami-Shell (man spricht es "O-Kammi") ist ein (weiterer) Versuch, auf dem Atari ST so etwas wie Unix-Gefühle aufkommen zu lassen. Das Programm wendet sich an alle, die die Möglichkeiten eines Kommandoin- terpreters denen des Desktops vorziehen. Die Shell ist vor allem beim Betrieb mit einer Festplatte ausgesprochen nützlich. Obwohl es schon einige Programme dieser Art gibt, gibt es gewichtige Gründe, die Okami-Shell zu benutzen und sich durch die folgende Anlei- tung zu arbeiten. Die Okami-Shell ist einer der Unix-orientierten Kommandointerpreter für den ST, der die Unix-Möglichkeiten der Ein/Ausgabe-Umleitung und des Pipelinings auch für die internen (in der Shell eingebauten) Kommandos ermöglicht. Die Ein/Ausgabe-Umleitung ist die Möglichkeit, die Standard- Ausgabe eines Programmes, d.h. alles, was mit printf etc. ausgegeben wird und normalerweise auf dem Bildschirm landet, sowie die Standard- Eingabe in eine Datei oder zu einem Gerät (z.B. zum Drucker) umzulei- ten. Die Umleitung funktio niert unter TOS mit dem GEM-Desktop a) nur bei TTP-Programmen, weil man nur bei diesen die Möglichkeit hat, eine Kommandozeile einzugeben, und b) nur bei Programmen, deren Compiler die Umleitung unterstützen. Die Okami-Shell führt die Umleitung selber durch, wodurch auch Programme, die ihre Kommandozeile nicht beachten (z.B. solche, die mit dem Pd-Modula-2-System erstellt wurden), umgeleitet werden können. Die Okami-Shell kann allerdings noch etwas mehr: sie ist ein universelles Utility, mit dem man nicht nur Programme starten, sondern auch Pro- gramme schreiben und debuggen usw. kann. Als Bonbon hat sie einen eingebauten UPN-Rechner mit ca. 80 Funktionen sowie einen Terminal- Emulator. Alles in allem bietet die Okami-Shell mehr interne Kommandos und Funktionen als jede andere für den Atari erhältliche Shell. Bei der Programmierung einer Shell oder eines Kommandointerpreters steht man immer vor der Frage, ob man für die in der Shell eingebauten Kommandos Unix-, MS-DOS- oder eine selbstausgedachte Schreibweise benutzen soll, d.h. ob man die Kommandos ls oder dir, mv oder rename, cp oder copy nennen soll oder ob man sich eingene Kommandonamen ausdenkt. Die Okami-Shell ist an den Unix-Bezeichnungen orientiert, ge- nauer gesagt an dem Unix-Derivat AIX, das z.B. auf dem IBM RT PC 6150 läuft. Natürlich müssen bei soetwas Abstriche gemacht werden, der Atari ist schließlich keine Unix-Maschine, und eine Shell ist kein Be- triebssystem. Wer sich in Unix einigermaßen auskennt, kann mit der Okami-Shell sofort loslegen. Die folgende Anleitung stellt die Verwendung der Shell dar, die Erklärung der internen Kommandos mit Syntax befindet sich in der Datei commands.doc. Um die vielen Versionen der Shell unterscheiden zu können, gibt das Kommando `ver' eine Information mit Versionsnummer und Kompilierungs- zeitpunkt aus. Zur Interpretation der Versionsnummer siehe tricks.doc. ---------------------------------------------------------------------------- SUPPORT Die Okami-Shell ist Public Domain, d.h. sie kann von jedermann benutzt und weitergegeben werden, ohne daß jemand etwas dafür zu bezahlen hat. Wer über E-Mail zu erreichen ist, sollte mir über das Maus- oder Usenet eine kleine Nachricht, evtl. mit Kommentaren, Anregungen und Kritik, zukommen lassen. Adresse siehe unten. Über den Support ist es jederzeit und für jeden möglich: 1) die neueste Version der Shell zu bekommen, 2) konfektionierte Versionen zu erhalten, in denen die Systembeschrän- kungen (Anzahl der Variablen, Funktionen etc.) verändert sind. Wer also eine Version braucht, die bis zu 2000 Variablen verwalten kann, kann ei- ne solche bekommen. Außerdem können beliebige Kommandos ausgeblen- det werden, um die Shell kleiner zu machen. Wer also z.B. den UPN- Rechner und das basep-Kommando nicht braucht, kann eine Shell erhal- ten, in der diese Kommandos nicht enthalten sind und die somit entspre- chend kürzer ist. 3) Außerdem ist eine "CLI-Only"-Version erhältlich, die nur die allerwich- tigsten Kommandos zur Bedienung der Shell enthält. Diese Version ist un- gepackt ca. 63 KB groß (die Vollversion ca. 130 KB) und kann auf Syste- men eingesetzt werden, auf denen die wichtigsten Kommandos als externe Programme zur Verfügung stehen. Es ist verboten, die Shell zu verkaufen oder unter einem anderen Namen zu vertreiben. Wer irgendwelche Teile des Programms oder der Quellen in eigenen Programmen benutzen will, darf dies tun, solange mein Name im Programm und in der Dokumentation erwähnt wird. Die Datei `copying' enthält genaue Hinweise zum Kopieren und Weiterge- ben der Shell. Das Programm wird voll unterstützt, d.h. es wird dynamisch weiterentwik- kelt, und jeder Anwender kann bei mir jederzeit die neueste Version be- stellen. Ebenso stehe ich bei Problemen und Wünschen zur Verfügung. Spenden sind natürlich auch willkommen, aber ausdrücklich nicht Vorraus- setzung für den Erwerb von neuen Versionen, Anleitungen oder sonstigen Hilfen (dies ist allen Pd-Programmierern zur Nachahmung empfohlen). Meine Adresse: Wolfram Rösler Augustastr. 44-46 D-5100 Aachen Tel. +49 (0)241 534596 oder +49 (0)241 504290 Mausnetz: Wolfram Roesler @ AC2 Usenet: wr@bara.oche.de Bei dieser Adresse kann für 15 DM eine gedruckte Version der Anleitung bezogen werden. Bitte bei allen Zuschriften die Versionsnummer und das Kompilierungsda- tum der Shell angeben (werden durch Eingabe von "ver" ausgegeben). Bei Fehlermeldungen bitte die Ausgabe von "ver -a" mitschicken. Wer irgendwelche Anregungen für weitere Versionen der Shell hat, kann sich damit jederzeit an mich wenden. ---------------------------------------------------------------------------- PROGRAMMFEHLER "Selbst der umsichtigste Programmierer kommt manchmal in Situa- tionen, wo das Programm nicht richtig funktioniert." Texas Instuments, "Individuelles Programmieren" Handbuch zu TI 58/58C/59, 1977 Der Software-Support deckt die Beseitigung von Fehlern in der Shell ab. Wer einen Fehler findet, sollte also nicht die Okami-Diskette in die Ecke schmeißen und sich einer anderen Shell zuwenden (die hat nämlich auch Fehler), sondern mir einen Hinweis mit möglichst genauer Fehlerbeschrei- bung schicken. Wenn man eine Diskette und Rückporto beilegt, bekommt man die korrigierte Version der Shell sobald wie möglich zurück. Wenn die Shell in Verbindung mit einem anderen Programm Probleme macht, sollte man dieses Programm gleich mitschicken. Bitte bei allen Fehlermel- dungen die Ausgabe von "ver -a" mitschicken. Natürlich kann ich keine Verantwortung für irgendwelche Schäden, die durch die Shell, ihre Anwendung oder die Unfähigkeit ihrer Anwendung verursacht werden, übernehmen. Wer also unbedingt df -mn | xargs rm -r {}/* ausprobieren muß, hat das Ergebnis selber auszubaden. ---------------------------------------------------------------------------- LIEFERUMFANG Zur Okami-Shell gehören die folgenden Dateien: KERN: sh.ttp Das Haupt-Shellprogramm. msh.prg Die Microshell zum Starten als GEM-Programm. msh.inf Konfigurationsdatei zur Microshell. profile Konfigurationsdatei beim Start der Shell. help Textdatei mit Syntaxerklärungen. EXTERNE KOMMANDOS: calc.sh Benutzerschnittstelle zum eingebauten UPN-Rechner. format.ttp Programm zum Formatieren von Disketten. gem.prg Programm zur Benutzung von Accessories. gem.rsc Resourcedatei dazu. showpic.sh Demo-Shellscript zur Anzeige von Bilddateien. QUELLEN: msh.c msh.prg gem.c gem.prg format.c format.ttp system.c Zum Einbinden der Shell in eigene Programme. DOKUMENTATION: readme Grundeinführung für den Anwender. doc\*.* Anleitungen. SONSTIGES: dial.inf Eine Beispieldatei für das dial-Kommando. okami.pic Das Titelbild. okami.dbl Ein Icon mit dem Okami-Schriftzeichen zum Einbau in eine Icondesk-Datei. _index Indexdatei für `ls -i'. Alle ausführbaren Programme wurden mit dem Programm-Packer von Th. Quester und M. Fritze gepackt. ---------------------------------------------------------------------------- SYSTEMANFORDERUNGEN "Wie der Name unschwer erkennen läßt, besitzt der Atari 520 ST einen enormen Hauptspeicher, nämlich ganze 512 KByte. Der eine oder andere kann sich vielleicht schwer vorstellen, wozu dieser Rie- senspeicher benötigt wird." Data Becker, "Das große GEM-Buch" (1985) Die Okami-Shell stellt folgende Anforderungen an das System: Rechner Läuft auf ST, TT usw. RAM Die Shell benötigt ca. 200 KB an Laufzeitspeicher => lauffähig auch auf 512KB-Maschinen. Empfohlen werden allerdings 1 MB oder mehr. Massespeicher Für die zum Lauf notwendigen Dateien werden minimal ca. 120 KB benötigt. Mit allen Hilfsdateien (Microshell, Profile,...) werden ca. 200 KB benötigt. Dazu kommen noch die über 300 KB für die Do- kumentation. Die Shell kann jedem Massespeicher betrieben werden. Für die Ver- wendung des Pipelinings ist es jedoch notwendig, daß auf einen Massespeicher (nicht notwendigerweise den, von dem die Shell ge- startet wurde) geschrieben werden kann. Für diesen Zweck kann auch eine eigene kleine Ramdisk angelegt werden (16-32K). Bildschirm Läuft fehlerfrei in hoher und mittlerer Auflösung. Der Betrieb in niedriger Auflösung ist möglich, aber einige interne Kommandos ge- hen davon aus, das pro Zeile 80 Zeichen zur Verfügung stehen (z.B. df und hd). Die Benutzung dieser Kommandos kann dann zu Störun- gen in der Bildschirmausgabe führen. In keinem Fall kommt es je- doch zu einem Programmabsturz. Sollte mit jeder Farb- und Schwarzweiß-Emulation funktionieren. Sollte auch mit allen Großbildschirm arbeiten (ungetestet mangels Großbildschirm). Die Shell unterstützt OverScan (siehe commands.doc zu dem internen Kommando "overscan"). Hardware Die Shell unterstützt Maus, Drucker und die RS232-Schnittstelle so- wie ein Modem. Es werden jedoch keine Geräte außer Bildschirm und Tastatur unbedingt benötigt (auch nicht die Maus). (Genauge- nommen werden nicht einmal Bildschirm und Tastatur unbedingt be- nötigt.) Betriebssystem Die Shell wurde unter TOS 1.2 und 1.4 auf einem Atari 1040 ST und Mega ST4 entwickelt und ist "sauber" programmiert, d.h. es erfolgt kein Zugriff auf undokumentierte oder veränderliche Systemadressen o.ä. Die Shell sollte daher mit jedem früheren und zukünftigen TOS zusammenarbeiten (abgesehen von Betriebssystemfehlern.) Software Jedes TOS- und TTP-Programm kann von der Shell als externes Kommando aufgerufen werden. GEM-Programme können aufgerufen werden, wenn die Shell selber als GEM-Programm gestartet wird, was z.B. der Fall ist, wenn msh.prg zum Start der Shell benutzt wird. Zum Verändern der Konfigurationsdateien profile und msh.inf ist ein Ascii-Editor erforderlich. ---------------------------------------------------------------------------- INSTALLATION Die Okami-Shell kann direkt von der Diskette gestartet werden. Siehe hierzu den folgenden Abschnitt. Ihre volle Effizienz entwickelt die Shell allerdings erst beim Einsatz von der Ramdisk oder Festplatte. INSTALLATION AUF RAMDISK Ich empfehle die selbstkomprimierende Maxidisk, da sie die optimale Speicher ausnutzung garantiert. Für die Shell sollten mindestens 200 KB Maxidisk oder ca. 300 KB einer anderen Ramdisk zur Verfügung stehen. Für den vollen Betrieb der Shell sollten folgende Dateien (am besten in einen eigenen Ordner) auf die Ramdisk kopiert werden: sh.ttp profile msh.prg msh.inf help okami.pic dial.inf _index in einem Unterordner namens doc: commands.doc <------ aus dem Anleitungsordner in einem Unterordner namens bin: *.sh format.ttp gem.prg gem.rsc ship.exe <------ für Festplattenbenutzer: das ship.prg der Harddisk-Utility-Disk Die Datei help wird für das Shell-Kommando "help" benutzt; wer diese Datei ausdruckt und neben den Rechner legt, kann sich den Platz auf der Ramdisk ebenfalls sparen. Dasselbe gilt für commands.doc, das außerdem ziemlich viel Platz beansprucht. (Auf der Platte - auf dem Papier aller- dings auch, außerdem wird commands.doc für die Online-Hilfe benötigt.) Die Dateien msh.prg und msh.inf gehören zusammen und werden zum Start der Shell als GEM-Programm benutzt. Wer von der Shell keine GEM-Programme starten will, braucht diese Dateien nicht. Auf die externen Kommandos wie gem und format kann man natürlich auch verzichten, nur muß man dann u.U. etwas häufiger ins Desktop zu- rück. Wer kein Modem hat, kann mit dem dial-Kommando nichts anfangen und braucht folglich auch kein dial.inf. Wer nicht bei jedem Systemstart das Titelbild sehen möchte, kann die Datei okami.pic umbenennen oder löschen. Auch auf profile kann man verzichten, allerdings wird die Shell dann mit den eingebauten Voreinstellungen initialisiert. => Die einzige Datei, die man wirklich braucht, ist sh.ttp. INSTALLATION AUF FESTPLATTE Bei der Installation der Shell auf Festplatte kommt echtes Unix-Feeling auf, vor allem wenn man die Shell nach dem Systemstart automatisch starten läßt (ich empfehle zum Autostart: TOS 1.0 den Autostarter aus dem Data Becker-Buch "Die besten Tips&Tricks für Atari ST", S. 24ff. TOS 1.2 den Autostarter "startgem.prg", der zu Superboot 6.0 ge- hört, siehe PD-Journal 9/90, S. 43ff. >= TOS 1.4 msh.prg im Desktop als Autostart-Applikation anmelden) Mit einigen Tricks, die im folgenden erklärt werden, kann man sich z.B. bei jedem Start der Shell Datum und Uhrzeit des letzten Systemstarts ausgeben lassen oder das aktuelle Arbeitsverzeichnis so einstellen, wie man die Shell zuletzt verlassen hat. Außerdem kann man alle Programme, die man auf der Festplatte hat, per Name starten lassen, egal in wel- chem Verzeichnis man sich gerade befindet, und es werden sogar alle RSC-Dateien gefunden. Man tippt also z.B. ein: edit datei.txt und es erscheint der Editor mit der Datei datei.txt, egal wo im Dateisys- tem der Editor sich befindet. Für die Shell sollte ein eigener Ordner eingerichtet werden, in den die oben unter INSTALLATION AUF RAMDISK aufgeführten Dateien kopiert werden. Außerdem ist es sinnvoll, eine kleine Ramdisk (16-32K) anzulegen und die Pipe-Operationen über diese laufen zu lassen. Siehe dazu weiter unten. Wenn man sich die Anleitungen der Shell auf die Festplatte kopiert, braucht man die Datei commands.doc nicht noch einmal in den Shell-Ord- ner zu kopieren. Dann muß allerdings der Dateiname von commands.doc in der Shell-Variablen HELPFILE gespeichert werden. Siehe dazu weiter unten. Wer sich sein Desktop mit Icondesk von Stefan Becker verschönert hat, kann die Icon-Datei okami.dbl direkt in die icons.img-Datei einbauen. INSTALLATION IM AUTO-ORDNER Es ist sehr sinnvoll, ein kleines Programm zu schreiben, das im Auto- Ordner gestartet wird und, wenn eine bestimmte Taste gedrückt ist, die Shell per Pexec ausführt. Wenn dies das erste Programm im Auto-Ordner ist, hat man immer die Gelegenheit, vor dem Start irgendwelcher Pro- gramme in die Shell zu gelangen und so z.B. defekte Programme, die das korrekte Hochfahren des Systems verhindern, zu deaktivieren. Die Shell führt keine AES-Aufrufe aus, die beim Start aus dem Auto-Ord- ner zu Problemen führen würden, da zu dieser Zeit das AES noch nicht initialisiert ist. Die Shell führt AES-Aufrufe erst dann aus, wenn der An- wender sie durch Eingabe des Kommandos `gon' explizit dazu auffordert. Aus diesem Grund ist ein Betreiben der Shell aus dem Auto-Ordner pro- blemlos möglich. INSTALLATION IM COOKIE-JAR Der Cookie-Jar ist eine Möglichkeit des Betriebssystems, mit der instal- lierte Programme dem System ihre Anwesenheit nebst Versionsnummer mitteilen können. Der Cookie-Jar wird erst ab TOS 1.6 vom Betriebssys- tem selber benutzt, kann aber bei allen früheren TOS-Versionen auch von Programmen installiert werden. Die Okami-Shell trägt sich unter der Ken- nung "OkSh" in den Cookie-Jar ein. Vorher installiert sie einen solchen, falls noch keiner vorhanden ist. Die Versionsnummer ist auf zwei Bytes aufgeteilt, bei Version 1.3 steht eine 3 im niedrigsten und eine 1 im nächsthöheren Byte. Mit dem internen Kommando `cookie' kann der Cookie-Jar ausgelesen werden. Siehe hierzu commands.doc. Wenn die Shell beendet wird, wird der vorherige Wert wieder als Cookie- jar-Adresse eingetragen. Beim Beenden der Shell mit shutdown wird als Cookiejar-Adresse 0 eingetragen. ---------------------------------------------------------------------------- START DER SHELL a) Direkt Die Shell wertet ihre Kommandozeile nach der folgenden Syntax aus: [-] [Flags] [[-- | -c] Cmd [Parameter]] Es bedeuten: - Es wird die Datei profile im aktuellen Directory geladen. Wenn - nicht angegeben ist, wird keine Profile-Datei geladen. (In Unix wird das - als erstes Zeichen von argv[0] übergeben. Das läßt sich in TOS nicht bewerkstelligen, also muß das - in der Kommandozeile stehen.) Flags Beliebige der Flags, die auch für das Kommando set benutzt wer- den können und das Verhalten der Shell global beeinflussen. Die Flags können also schon in der Kommandozeile eingestellt werden, was nützlich ist, wenn kein Profile benutzt wird. Die Flags können mit + oder - beginnen. Siehe commands.doc für weitere Details. -- Stellt das Ende der Flags dar und signalisiert, daß die weiteren Pa- rameter zu `Cmd' gehören. -- wird nur benötigt, wenn `Cmd' mit einem Minus- oder Pluszeichen beginnt. -c Signalisiert, daß es sich bei `Cmd' um ein auszuführendes Komman- do (intern oder extern) handelt. Wenn -c nicht benutzt wird, wird Cmd als der Dateiname eines auszuführenden Shellscripts betrachtet. Cmd Ein auszuführendes Kommando oder Shellscript. Wenn Cmd angege- ben ist, wird die Shell nach seiner Ausführung beendet. Wenn kein Cmd angegeben ist, wird die Shell interaktiv. Para Optionale Parameter für Cmd. Anmerkung: Über den Software-Support kann eine Shell bezogen werden, die sich im Hinblick auf das übergebene Minuszeichen genau andersherum verhält, d.h. sie initialisiert sich mit dem Profile immer, außer es wird ein Minuszeichen übergeben. Beispiele: sh Die Shell wird interaktiv gestartet. Es wird kein Profile geladen. sh - Die Shell wird interaktiv gestartet. Die Datei profile im aktuellen Directory oder (falls gesetzt) die in der Environment-Variablen OKSH_PROFILE angegebene Datei wird geladen. Dies ist der nor- male Start der Shell. sh - -i Die Shell wird interaktiv gestartet, die Datei profile wird geladen, und es wird der Insert-Modus des Zeileneditors abgeschaltet (-i). sh myscript Die Datei myscript wird als Shellscript ausgeführt, danach wird die Shell beendet. sh -x myscript Die Datei myscript wird als Shellscript ausgeführt, danach wird die Shell beendet. Vorher wird das Flag x gelöscht, wodurch die Shell beim Start von Binärprogrammen das aktuelle Verzeichnis nicht auf das Verzeichnis einstellt, in dem die Programmdatei enthalten ist. sh -L <myscript Das Flag L wird gelöscht, wodurch die Shell Kommandos von der Standardeingabe (statt mit dem Zeileneditor von der Tastatur) ein- liest. Dadurch wird die Datei myscript ausgeführt. Diese Art des Startens eines Shellscripts unterscheidet sich nur geringfügig von dem direkten Angeben des Shellscripts und kann z.B. benutzt wer- den, um Kommandos von einer Pipeline oder einer Schnittstelle aus- zuführen. sh -c ver Die Shell führt das Kommando `ver' aus und terminiert. b) Indirekt Die Shell kann indirekt von jedem Programm aus mit der GEMDOS-Funk- tion Pexec gestartet werden. Dies geschieht z.B. beim Aufruf von der Mi- croshell. Da die Shell den Environment-String benutzt, sollten Programme, die das nicht tun, als letzten Parameter von Pexec eine (long)0 überge- ben (und nicht einen Leerstring). Wenn der Shell dabei ein Parameter- string übergeben wird, so wird dieser wie oben beschrieben ausgeführt. Der Parameterstring kann der Shell auch nach dem xArg-Verfahren über- geben werden. Wenn die Shell als Login-Shell gestartet werden soll und es möglich sein soll, GEM-Programme von der Shell aus zu starten, muß die Shell mit der Microshell (msh.prg) gestartet werden. Dazu müssen folgende Voraus- setzungen zutreffen: 1) Im selben Directory wie sh.ttp stehen die Dateien msh.prg und msh.inf. 2) Die Datei msh.inf enthält mindestens die folgende Zeile: sh.ttp - Dann wird die Shell nach Doppelklick auf msh.prg automatisch als Login- Shell gestartet. Es können alle GEM-Programme von der Shell aus ausge- führt werden. Siehe hierzu auch msh.doc. Wenn die Shell auf diese Weise vom Desktop aus gestartet wird, sollte das Profile die Zeile trap cursor -v enthalten. Dann wird nach dem Ende der Shell automatisch der Cursor abge schaltet (auf dem Desktop stört er ziemlich). Siehe hierzu auch commands.doc. c) Über den Shellpointer (_shell_p) Der Shellpointer befindet sich in Adresse 0x4F6 und enthält einen Zeiger auf eine Funktion, die ein ihr übergebenes Kommando ausführt. Auf diese Weise ist es möglich, aus einem von der Shell gestarteten Programm aus Shellkommandos auszuführen, ohne daß die Shell nochmal geladen werden muß. Dies funktioniert z.B. mit Programmen wie Rufus oder der mitgelie- ferten system()-Funktion (siehe system.c und system.doc). Ein Beispiel für die Verwendung ist das mitgelieferte gem.prg. Die Funktion, deren Adresse in 0x4F6 hinterlegt wird, hat folgende Syn- tax: int Fct(cmd) char *cmd; cmd ist ein String mit dem auszuführenden Kommando. Dies kann ein be- liebiges Shell-Kommando sein. Mehrere Kommandos können durch `;' ver- kettet werden. Wenn ein leerer String oder ein NULL-Zeiger übergeben wird, arbeitet die Shell im Dialogmodus, ansonsten wird nur cmd ausge- führt. Zurückgegeben wird der Rückgabewert des Kommandos. Achtung: Bei dieser Art des Aufrufes wird die bereits laufende Shell aus- geführt. Das bedeutet, daß alle Shellvariablen und Shellfunktionen der lau- fenden Shell benutzt und verändert werden können. Die vollständige Reen- tranz der Shell kann jedoch nicht garantiert werden. Insbesondere sollten mit einer auf diese Weise gestarteten interaktiven Shell keine externen Programme aufge rufen werden. (was allerdings teilweise möglich ist und von dem betreffenden Programm abhängt.) ---------------------------------------------------------------------------- KONFIGURATION Wenn der Shell als einziger Parameter ein Minuszeichen übergeben wird, sucht sie nach dem Start im aktuellen Verzeichnis eine Datei mit dem Namen profile. Wenn die Environment-Variable OKSH_PROFILE gesetzt ist, wird stattdessen die in dieser Variable angegebene Datei benutzt. Wenn diese Datei vorhanden ist, wird sie wie ein Shellscript (siehe dazu weiter unten) ausgeführt. Das Profile kann eine Einschaltmeldung auf dem Bildschirm ausgeben und Shellvariablen wie z.B. das Prompt (PS1) setzen. Außerdem können die Shell-Flags eingestellt werden (siehe dazu das in- terne Kommando `set' in commands.doc). Das Profile kann alle Aktionen ausführen, die ein normales Shellscript auch ausführen kann. Siehe hierzu auch tricks.doc. ---------------------------------------------------------------------------- KOMMANDOEINGABE a) Von der Tastatur Wenn die Shell im Dialogmodus gestartet ist, können nach dem Prompt (i.d.R. ein Dollarzeichen) Kommandos eingegeben werden. (Das mitgelie- ferte Profile stellt das Prompt um, so daß im Prompt immer das augen- blickliche aktuelle Directory zu sehen ist.) Mit dem internen Kommando keydef kann jede beliebige Taste umdefiniert werden. Das bedeutet, daß alle der unten angeführten Tastenfunktionen ungültig werden können, wenn die jeweiligen Tasten redefiniert werden. Die einzigen Funktionen, die nicht umdefiniert werden können, sind ENTER und Ctrl Shift Undo. Für weitere Informationen siehe commands.doc zum Thema keydef. Bei der Eingabe werden folgende Sondertasten benutzt: Backspace bewegt den Cursor nach links und löscht das dort stehende Zeichen. Pfeil auf Es wird das zuletzt eingegebene Kommando angezeigt. Dieses kann mit ENTER übernommen oder mit Backspace editiert werden. Durch wiederholten Druck auf Pfeil auf wird das vorletzte Kommando an- gezeigt usw. Es werden maximal 100 Kommandos gespeichert (wer mehr braucht, benutze den Software-Support, um eine entsprechend angepaßte Version der Shell zu erhalten.) Diese Eigenschaft der Eingabe nennt man "History". Shift Pfeil auf Wie Pfeil auf, aber es wird die letzte Zeile aus der History ange- zeigt, die mit der bisherigen Eingabe übereinstimmt. Gibt man also ein "ls " und drückt Shift Pfeil auf, dann wird das letzte ls-Kom- mando zurückgeholt. Der Zeiger in der History-Liste steht dann hin- ter dieser Zeile, ein weiterer Druck auf Shift Pfeil Auf bringt also das vorletzte ls-Kommando zurück usw. Ctrl Pfeil auf Wie Pfeil auf gefolgt von einem Druck auf ENTER, es wird also das zuletzt eingegebene Kommando nicht nur angezeigt, sondern auch ausgeführt. Geht auch zusammen mit Shift. Pfeil ab Zeigt das nächste Kommando in der History-Liste an. Mit Pfeil auf und Pfeil ab kann man also in den in der History-Liste gespeicher- ten Kommandos blättern. Shift Pfeil ab Analog zu Shift Pfeil auf. Ctrl Pfeil ab Wie Pfeil ab gefolgt von einem Druck auf ENTER, analog zu Ctrl Pfeil auf. Shift Esc Dateinamen-Vervollständigung für alle Dateien, die auf ein Suchmus- ter passen. Siehe unten. Esc Dateinamen-Vervollständigung für eine Datei. Siehe unten. Pfeil links/rechts bewegen den Cursor: mit Shift zum Zeilenanfang/ende, mit Control jeweils ein Wort nach links/rechts, sonst jeweils ein Zeichen nach links/rechts. Delete mit Control: löscht die Zeile von der Cursorposition bis zum Zeile- nende. Sonst: löscht das Zeichen unter dem Cursor. Shift Space Speichert die aktuelle Position für Pfeil rechts. Siehe unten. Clr Home Die Eingabezeile wird gelöscht. Help Es wird eine Erklärung des eingegebenen Kommandos ausgegeben. Siehe unten. Ctrl Shift Undo Für diese Eingabezeile wird die Tasten-Redefinition ausgeschaltet. Die Eingabe verhält sich also so, als ob seit dem Start der Shell keine keydef-Kommandos ausgeführt worden wären. Die Funktion wird durch ein Klingelzeichen bestätigt. Control F Es erscheint eine Fileselect-Box, der ausgewählte Dateiname wird in die Eingabe übernommen. Das geht nur, wenn gon aktiv ist (siehe commands.doc zum Stichwort gon). Control P Es wird Hardcopy ausgeführt. Dies geschieht durch Aufruf der Shellfunktion "screensave". Die Voreinstellung dieser Funktion ist ein einfacher Aufruf des internen Kommandos "hardcopy", wodurch der Bildschirminhalt auf dem Drucker ausgegeben wird. In der Datei tricks.doc ist eine screensave-Funktion angegeben, durch die die Hardcopy in eine Datei geschrieben wird. Control A Der Bildschirm wird dunkelgeschaltet. Um diesen Modus anzuzeigen, läuft ein heller Streifen über den Bildschirm. Nach Druck auf eine der Shifttasten, Control oder Alternate kann man weiterarbeiten. Alternate Space Es werden Uhrzeit und Datum angezeigt, bis die Alternate-Taste losgelassen wird. Control D Die Shell wird beendet. Es können beliebige Ascii-Codes in der Schreibweise `^ooo' eingegeben werden, wobei ooo eine dreistellige Oktalzahl ist. Um z.B. ein Escape zeichen in eine Eingabe einzubauen: echo "Jetzt kommt ein Esc: ^033 das war das Esc" Auf diese Weise können alle VT52-Sequenzen benutzt werden. Siehe auch `echo' in commands.doc. Dateinamen-Vervollständigung (Filename-Completion): Die Shell bietet die Möglichkeit, nur einen Teil eines Dateinamens einzu geben und diesen dann zu dem vollen Dateinamen expandieren zu lassen. Dazu gibt es zwei Möglichkeiten: 1) Nach Druck auf Taste Shift-Escape wird das zuletzt eingegebene Wort zu allen Dateinamen expandiert, die nach den Regeln der erweiterten Wildcards auf dieses Wort passen. Beispiel: $ cat *.c<SHIFT ESC> erzeugt $ cat sh.c cmds.c utl.c ... 2) Nach Druck auf die Taste ESC kann der Anwender aus den auf das letzte Wort passenden Dateien eine auswählen. Wenn nur eine Datei paßt, wird diese direkt übernommen, ansonsten kann eine Datei mit fol- genden Tasten ausgewählt werden: Pfeil li./re. die jeweils nächste/vorige Datei. Pfeil auf/ab zum Anfang/Ende der Liste. Leertaste Dateilänge und Anzahl der passenden Dateien wer- den ausgegeben. Hierbei bedeutet `4/10' die vierte Datei von insgesamt zehn. Return der gerade angezeigte Dateiname wird übernom- men. ESC die Auswahl wird abgebrochen, die bisherige Einga- be bleibt unverändert. Clr Home die Auswahl wird abgebrochen, das Suchmuster wird aus der Eingabe entfernt. Help eine Tastenübersicht wird angezeigt. Sowohl für Pfeil links als auch für ESC gilt, daß die Funktion des einge gebenen Wortes mit dem Shell-Flag f verändert werden kann. Wenn die- ses Flag gesetzt ist (set +f), dann stellt das eingegebene Wort ein Präfix dar, z.B. steht `abc' dann für alle Dateien, deren Name mit abc anfängt. Wenn das Flag f nicht gesetzt ist (set -f), steht das eingegebene Wort nur für die Dateien, die (nach den Regeln für erweiterte Wildcards) auf dieses Wort passen, `abc' steht dann also nur für die Datei abc. Zur Verwendung der Help-Taste: Mit der Help-Taste kann jederzeit, und zwar ohne die Eingabe zu stören, zu einem Kommando die entsprechende Anleitung aus der Datei commands.doc oder einer anderen Hilfsdatei angezeigt werden. Will man z.B. eine Diskette formatieren, so tippt man das Kommando "format" ein und überlegt dann, wie die Parameter noch waren - dann hilft ein Druck auf Help, und es erscheint die Anleitung zu format. Anschließend kann die Eingabe fortgesetzt werden. Das funktioniert auch, wenn bereits Parameter nach format eingegeben worden sind. Wenn man die Help-Taste bei leerer Kommandozeile drückt, wird man nach dem zu erklärenden Kommando gefragt. Bei der Angabe des zu erklärenden Kommandos gelten die Regeln für er- weiterte Wildcards, d.h. mit "r*" wird das erste Kommando erklärt, das mit r beginnt usw. Beispiel: $ format A: <HELP> Eingabe format - Formatieren von Disketten Ausgabe ..... (usw.) $ format A: * weiter gehts (In diesem Beispiel steht <HELP> für das Drücken der Help-Taste und * für die Cursor-Position am Ende. $ ist das Shell-Prompt.) Der Pfadname der Datei commands.doc muß in der Shell-Variablen HELPFILE gespeichert sein. Die Voreinstellung ist $HOME\doc\commands.doc. Wenn die Variable HELPFILE nicht gesetzt ist, wird die Datei help.txt im aktuellen Directory benutzt. Wenn das Stichwort in der in HELPFILE angegebenen Hilfsdatei nicht gefunden wird, sucht die Shell nach einer Datei folgenden Namens: pfad\name.ext Pfad ist einer der in der Shell-Variablen MANPATH angegebenen Pfade, und ext ist einer der in der Shell-Variablen MANEXT angegebenen Exten- der. Name ist das eingegebene Stichwort. Das Suchen der Datei erfolgt analog zum Suchen einer Programmdatei mit den Variablen PATH und SEXT/XEXT. Beispiel: MANPATH=$HOME/doc, MANEXT=.doc, Eingabe: lharc. Dann sucht die Shell nach einer Datei namens $HOME/doc/lharc.doc. Die Datei wird, falls gefunden, mit den eingebauten Kommando pg ange- zeigt. Um möglichst schnellen Zugriff auf die Hilfsdatei zu ermöglichen, erstellt die Shell nach dem Laden einen Index, in dem die einzelnen, in der Da- tei enthaltenen Kommandos verzeichnet sind. Dieser Index wird nach der Erstellung in eine Datei abgespeichert, die denselben Pfad und Dateina- men wie die Hilfsdatei, aber den Extender .idx hat (z.B. commands.idx). Beim nächsten Laden der Hilfsdatei wird der Index aus dieser Datei ge- laden, was besonders bei Festplatten eine enorme Beschleunigung gegen- über dem Neuerstellen des Index im Speicher darstellt. Wenn die Hilfsdatei neuer ist als die Indexdatei, wird ebenfalls ein neuer Index erstellt und abgespeichert. Dadurch wird erreicht, daß die Indexda- tei immer zu der Hilfsdatei paßt, auch wenn letztere verändert wird. Wenn man eine neue Indexdatei erstellen will, genügt es, die alte Index- datei zu löschen. Die Verwendung einer Indexdatei kann mit dem Shell-Flag -H unterbunden werden. Dies ist wichtig für Diskettenbenutzer, bei denen das Laden der Indexdatei länger dauert als die Neuerstellung des Index im Speicher. Siehe hierzu commands.doc zum Thema `set'. Anstelle von commands.doc kann auch jede andere Datei als Hilfsdatei benutzt werden. Damit ein Kommando in der Datei erkannt wird, muß die Datei folgende Regeln erfüllen: 1) Vor dem Text, der das Kommando erklärt bzw. der zu dem Kommando ausgegeben werden soll, muß eine Zeile stehen, die mit fünf Minuszeichen beginnt. 2) Direkt nach dieser Zeile muß eine Zeile stehen, die mit dem Komman- do beginnt. Das Kommando geht vom Anfang der Zeile bis (exkl.) zum ersten Nicht-Buchstaben (Buchstaben sind a-z und A-Z, keine Umlaute, kein ß) und darf maximal 10 Zeichen lang sein. Danach können weitere Informationen stehen, die nicht beachtet werden. 3) Der auszugebene Text beginnt mit der unter 2) beschriebenen Zeile und geht bis zur nächsten Zeile, die mit fünf Minuszeichen beginnt (exkl.). Beispiel: ----- 1) ls - Anzeigen von Directories 2) 3) (Weitere Angaben) 4) 5) ----- 6) Bei der Eingabe von "ls <HELP>" werden die Zeilen 2) bis 5) ausgege- ben. Natürlich kann man auch eine Kopie von commands.doc anfertigen und dort einige weitere beliebige Informationen eintragen, die unter entspre- chenden Stichworten abgefragt werden können. Die Ausgabe erfolgt wie mit dem Kommando "pg". Siehe hierzu commands.doc. TECHNISCHER HINWEIS: (nur für Programmierer von Interesse) Wenn die Hilfsdatei im Speicher steht und von der Shell aus ein anderes Programm gestartet wird, übergibt die Shell diesem in der Environment- Variablen _HELP_ADR die Adresse eines Pointers auf die geladene Hilfs- datei. Auf diese Weise kann eine Subshell auf die bereits geladene Datei zugreifen, ohne diese selber laden zu müssen (was einen nicht unerhebli- chen Aufwand an Speicherplatz bedeuten würde.) Die Shell liest den Inhalt von _HELP_ADR direkt nach der Initialisierung der Variablen aus dem Environment und löscht danach die Shellvariable _HELP_ADR. Beim Aufruf weiterer Programme wird diese Variable nur während der Erstellung des Environments für das neue Programm ange- legt. Die Variable _HELP_ADR ist also für den Anwender der Shell nie- mals sichtbar, befindet sich aber im Environment aller gestarteten Pro- gramme. Für die Übergabe ist es notwendig, daß noch mindestens ein Platz in der Variablentabelle frei ist. Das Format von _HELP_ADR ist 0xAAAAA:0xBBBBB , wobei AAAAA die Adresse eines Pointers ist (hexadezimal). Dieser Poin- ter zeigt auf den Text der geladenen Datei. 0xBBBBB ist die Adresse ei- ner internen Indextabelle, die die Shell zum schnellen Zugriff auf die ge- ladenen Daten benutzt. Diese Indextabelle ist ein Array von Strukturen des Typs struct { char Name[12]; long Offset; } HelpIdxTyp; Name ist der Name eines Kommandos und Offset ist die Byte-Entfernung der Erklärung dieses Kommandos von dem Beginn des Textes (der durch den Zeiger in der Adresse 0xAAAAA angegeben wird). Das Ende dieser Tabelle ist durch einen Eintrag mit Offset=-1L markiert. Die angelegte Indexdatei stellt ebendiesen Array dar. (0xAAAAA ist also vom Typ (char **), während 0xBBBBB vom Typ (HelpIdxTyp*) ist.) ACHTUNG: auf keinen Fall darf der Pointer verändert werden. b) Von der Standardeingabe Wenn das Flag L nicht gesetzt ist, ist der Zeileneditor ausgeschaltet, und die Shell liest Kommandos von der Standardeingabe. Das bedeutet, daß weder die Editierfunktionen noch die sonstigen Funktionen des Zeilenedi- tors, wie Filename Completion, Fileselect-Box, Help-Taste usw. zur Verfü- gung stehen. Der Sinn dieses Modus ist, Kommandos von etwas anderem als der Tastatur, z.B. von einer Schnittstelle, einer Datei oder einer Pipe, einzulesen. Um den Zeileneditor schon beim Start der Shell auszuschalten, muß beim Start von sh.ttp das Flag -L angegeben werden. Innerhalb der Shell kann dieselbe Wirkung durch Eingabe von "set -L" erreicht werden. Mit "set +L" wird der Zeileneditor wieder eingeschaltet. Wenn der Zeileneditor abgeschaltet ist, kann die Shell nur durch Eingabe von "exit" oder durch Druck auf Ctrl-Z beendet werden. c) Aus einer Datei Es ist möglich, Dateien zu schreiben, die Shell-Kommandos enthalten und diese Dateien Kommando für Kommando von der Shell ausführen zu las- sen. Solche Dateien werden als Shell-Scripts (oder in der MS-DOS-Welt als Batch-Dateien) bezeichnet. Ein Shell-Script kann wiederum weitere Scripts ausführen usw., wobei die Tiefe der Schachtelung durch den zur Verfügung stehenden Speicher und die systembedingte Maximalanzahl of- fener Dateien begrenzt ist. Rekursive Shellscripts sind natürlich auch möglich. Für die Kommandos in Shell-Scripts gelten dieselben Regeln wie für Kommandos, die über die Tastatur eingegeben werden. Leider ist die Ausführung von Shell-Scripts derjenige Punkt, an dem die Okami-Shell und die normalen Unix-Shells am weitesten auseinanderklaffen, da beim Aufruf eines Shell-Scripts unter Unix dieses i.d.R. nicht von der Shell selber ausgeführt wird, sondern die Shell startet sich selber nochmals, um das Script auszuführen (Subshell). Auf dem ST ist diese Vorgehensweise we- gen des begrenzten Speichers nicht zu empfehlen, weswegen jedes Shell- script von der Shell selber ausgeführt wird. Dies hat Konsequenzen z.B. bei der Ein/Ausgabeumleitung von Shell-Scripts und den einem Script übergebenen Parametern. Außerdem kann jedes Script auf alle Shellvari- ablen der aufrufenden Shell zugreifen und diese verändern. Bei der Ausführung eines Shellscripts wird das Script erst vollständig in den Speicher geladen und dann im Speicher ausgeführt. Das liefert be- sonders bei der Ausführung von Diskette enorme Geschwindigkeitsvorteile. Genügend Speicher ist normalerweise immer vorhanden, wenn man be- denkt, daß Scripts i.d.R. kleine Dateien (<5 KB) sind. Bei Shellscripts gibt es die Möglichkeit, Programmierstrukturen wie if und while zu benutzen, die bei Tastatureingabe wenig Sinn machen. Damit ist es in der Tat möglich, Shellscripts zu schreiben, die wie ein Programm einer höheren Programmiersprache laufen. Siehe hierzu showpic.sh und commands.doc. Es gibt vier Arten von Kommandos: 1) interne Kommandos, 2) externe Kommandos, 3) Shellfunktionen, 4) Kommentare. INTERNE KOMMANDOS Ein internes Kommando ist ein Kommando, durch das eine Funktion in- nerhalb der Shell ausgeführt wird, das also in der Shell eingebaut ist. In- terne Kommandos werden durch Eingabe ihres Namens aufgerufen. Genaue Erklärungen aller interner Kommandos befinden sich in der Datei commands.doc. EXTERNE KOMMANDOS Ein externes Kommando ist nicht in der Shell eingebaut, sondern in einer Datei auf einer Diskette, Ramdisk oder Festplatte vorhanden. Hierbei kann es sich sowohl um eine ausführbare Datei (.PRG, .TOS etc.) als auch um ein Shellscript handeln. Externe Kommandos können durch Eingabe des vollständigen Pfadnamens der entsprechenden Datei, aber auch durch Eingabe des Kommandona- mens (des Dateinamens ohne Pfad und Extender) gestartet werden. Die zugehörige Datei wird auf den Pfaden gesucht, die in der Shell-Variablen PATH gespeichert sind. Mit dem hash-Kommando kann der Pfad eines Kommandos der Shell mit- geteilt werden, ohne daß er in $PATH enthalten ist. Externe Kommandos können nur ausgeführt werden, wenn ihr Datei-Ex- tender einem der in den Shell-Variablen XEXT und SEXT gespeicherten entspricht. (Es kann jedoch jede Datei, unabhängig vom Dateinamen, ex- plizit als Shellscript oder Binärdatei ausgeführt werden, und zwar mit den Kommandos `.' und `exec'.) Siehe hierzu auch den Abschnitt über externe Kommandos in commands.doc. Externen Programmen werden die Parameter nach dem xArg-Verfahren übergeben, wenn das Shell-Flag `a' gesetzt ist (siehe commands.doc zum Thema `set'). Dies ermöglicht die Übergabe von beliebig vielen Parame- tern, während Gemdos die Parameter auf 125 Zeichen beschränkt. Achtung: einige (wenige) Programme vertragen sich damit nicht und laufen nur, wenn die xArg-Übergabe mit `set -a' unterbunden wird. Dazu gehört z.B. der Entpacker `unzip'. SHELLFUNKTIONEN Shellfunktionen sind Shellscripts, die resident im Speicher gehalten wer- den. Sie haben dieselben Eigenschaften wie Shellscripts und können des- halb auch genauso programmiert werden. Alles, was über die Verwendung von Shellscripts gesagt wird, gilt auch für Shellfunktionen. Jede Shellfunktion hat einen Namen, der bis zu 80 Zeichen lang sein darf. Groß- und Kleinschreibung wird unterschieden, d.h. "hallo" und "Hallo" sind zwei verschiedene Shellfunktionen. Bei der Ausführung haben Funktionen die oberste Priorität, kommen also noch vor den internen Kommandos. Es ist also möglich, interne Komman- dos umzudefinieren, indem man eine Shellfunktion mit demselben Namen anlegt. Innerhalb dieser Funktion kann auf das ursprüngliche Kommando zugegriffen werden, indem man dem Kommando ein Ausrufezeichen (ohne Leerzeichen) vorstellt. Die Syntax einer Deklaration von Shellfunktionen ist: [Funktionsname] "(" Dateiname ")" (1) oder Funktionsname "()" (2) "{" {Zeilen des Funktionsrumpfes} "}" oder Funktionsname "()" (3) "{}" (1) In der ersten Fassung wird die angegebene Datei als Shellscript in den Speicher geladen und unter dem Namen der Funktion abgespeichert. Wenn kein Funktionsname angegeben ist, wird der Basisname des Datei- namens (ohne Extender) als Funktionsname benutzt. In dieser Fassung entspricht die Shellfunktion also einem speicherresidenten Shellscript. Wenn die angegebene Datei eine ausführbare Programmdatei ist, wenn al- so ihr erstes Wort 0x601a ist, wird das Programm geladen und eine Shellfunktion erzeugt, die das Programm mit exec -x startet. Auf diese Weise ist es möglich, auch Binärprogramme resident im Speicher zu hal- ten und ohne Disketten- oder Plattenzugriffe beliebig oft zu starten. ACHTUNG: Die Vorgehensweise dabei beruht auf der Fähigkeit der Gem- dos-Funktion Pexec, Binärprogramme zu laden und erst zu einem späte- ren Zeitpunkt unter Angabe der Basepage-Adresse zu starten. Die Doku- mentation von Atari zu diesem Feature ist kurz und eindeutig; sie lautet: "Finger davon". Nichtsdestoweniger funktioniert es, aber es besteht keine Garantie, daß es immer oder mit allen Programmen oder Betriebssystem- versionen funktioniert. (2) In der zweiten Fassung wird die Funktion von der Tastatur oder dem Shellscript, in dem die Deklaration steht, gelesen. Wenn bereits eine Funktion mit dem angegebenen Namen existiert, wird sie umdefiniert. Wenn der Funktionsrumpf leer ist, wenn also die Zeilen mit { und } di- rekt aufeinander folgen, wird die Funktion gelöscht. In dieser Fassung wird die Eingabe verkürzt, d.h. Leerzeilen, Kommentar- zeilen und führende Leerzeichen werden nicht mit abgespeichert. (3) In der dritten Fassung wird die Funktion gelöscht. Das geht auch mit dem Kommando `unset Funktionsname'. Die zweite und dritte Fassung erwarten also mehr als eine Zeile. Die weiteren Zeilen der Deklaration werden von der sog. "Sekundäreingabe" erwartet, also von dem Gerät oder der Datei, von der augenblicklich Kommandos gelesen werden (das ist nicht immer die Standardeingabe). Wenn es sich dabei um die Tastatur handelt, erscheint als Prompt der In- halt der Shellvariablen PS2. ACHTUNG: In keinem Fall darf zwischen Funktionsname und der geöffne- ten Klammer ein Leerzeichen stehen. Beispiele: hallo(hallo.sh) initialisiert eine Funktion namens "hallo". Die Funktion entspricht dem Shellscript hallo.sh. hallo (hallo.sh) ruft das Kommando hallo mit dem Parameter (hallo.sh) auf, ist also KEINE Deklaration einer Shellfunktion. (Schuld daran ist das Leer- zeichen nach "hallo".) (c:/bin/test.sh) initialisiert eine Funktion aus der Datei c:/bin/test.sh. Da kein Funktionsname angegeben ist, wird der Basisname der Datei be- nutzt, es wird also die Shellfunktion "test" erzeugt. (Nebenbei be- merkt: dadurch wird das interne Kommando "test" umdefiniert.) (c:/bin/hallo.prg) lädt das Programm hallo.prg und erzeugt eine Shellfunktion namens hallo, die das geladene Programm startet. hallo hat dabei folgenden Funktionsrumpf: exec -lg c:/bin/hallo.prg 0xnnnn wobei nnnn die beim Laden ermittelte Adresse der Basepage von hallo.prg ist (hexadezimal). hallo() { echo Hallo, wie gehts? read _ echo Es freut mich, daß es Dir $_ geht. unset _ } definiert die Funktion hallo mit dem angegebenen Funktionsrumpf. Die Verwendung von Shellvariablen ist möglich; in diesem Fall wird die Variable _ (Underscore) benutzt, die für temporäre Verwendun- gen zur Verfügung steht. Diese Deklaration kann sowohl in einem Shellscript stehen als auch über die Tastatur eingegeben werden. Bei Tastatureingabe erscheint das Prompt $PS2. ls() { !ls -C $* } Das interne Kommando ls wird so umdefiniert, daß die Option -C immer aktiv ist. Dies geschieht durch Definition einer Shellfunktion mit Namen ls, die das interne Kommando durch !ls aufruft. alias ls !ls -C hat dieselbe Wirkung. hallo() {} Die Shellfunktion hallo wird gelöscht. hallo() { } Dito. unset hallo Dito. () (weder Funktions- noch Dateiname angegeben) ist ein Syntaxfehler. Mit dem internen Kommando "fcts" kann eine Liste sämtlicher Shellfunk- tionen erzeugt werden. Die Definition einer beliebigen Shellfunktion kann mit dem Kommando "type" ausgegeben werden. Siehe hierzu commands.doc. Es gehört zur Philosophie von Unix, daß man an der reinen Eingabe nicht erkennen kann, ob es sich bei dem eingegebenen Kommando um ein in- ternes Kommando, eine ausführbare Datei, ein Shellscript oder eine Shell- funktion handelt. Um das herauszufinden, gibt es das interne Kommando `type'. Siehe hierzu commands.doc. KOMMENTARE Eine Eingabe gilt als Kommentar, wenn sie mit einem Doppelkreuz (#) beginnt oder wenn sie nur aus einer leeren Zeile besteht. Kommentare werden von der Shell nicht weiter beachtet und sind nützlich zum Doku- mentieren von Shellscripts. Die Tastatureingabe von Kommentaren ist zwar möglich, aber nicht unbedingt sinnvoll. --------------------------------------------------------------------- ERWEITERTE WILDCARDS Die Okami-Shell erlaubt für die Angabe von Dateinamen ein Wildcard- System, das weit über das von Gemdos gestellte hinausgeht. Die einzigen Gemdos-Wildcards sind * und ?, wobei ein ein Dateiname nur einen Stern enthalten darf, und den nur am Ende von Name oder Extender. Bei "**" gibt es Probleme, "*hallo*" liefert nicht alle Dateinamen, die "hallo" ent- halten usw. Die erweiterten Wildcards der Okami-Shell orientieren sich an denen, die von der Original-Unix-Shell zur Verfügung gestellt werden. Es bedeuten: * beliebig viele, auch null, beliebige Zeichen. ? genau ein beliebiges Zeichen. [abcd] genau ein Zeichen, und zwar eins der in den Klammern ste- henden. Es dürfen beliebig viele Zeichen angeführt sein. [a-g] genau ein Zeichen, und zwar a, b, ... oder g. Das Minuszei- chen bedeutet also "bis". [~abc] genau ein Zeichen, und zwar ein beliebiges bis auf die Zei- chen in den eckigen Klammern. Es dürfen beliebig viele Zei- chen angeführt sein. Der Punkt zwischen Dateiname und Extender wird dabei wie jedes andere Zeichen behandelt, "*" paßt also auf alle Dateinamen und nicht nur auf die ohne Extender. Beispiele: * alle Dateinamen. *.* alle Dateinamen, die einen Extender haben. *.? alle Dateinamen, deren Extender aus genau einem Zei- chen besteht. *.[co] alle Dateinamen mit Extender .c oder .o. *.[~co] alle Dateinamen außer denen mit Extender .c und .o. [abcd]*[xyz] alle Dateinamen, deren erstes Zeichen a, b, c oder d und deren letztes Zeichen x, y oder z ist. Der Punkt, der den Extender einleitet (falls vorhanden), kann irgendwo dazwischen stehen. a[0-9] alle Dateinamen, die aus a, gefolgt von einer Ziffer be- stehen, also a0, a1, ..., a9. ??[a-z][0-9] alle Dateinamen, die aus zwei beliebigen Zeichen, gefolgt von einem Buchstaben und einer Ziffer bestehen. Wenn das Shell-Flag w nicht gesetzt ist, sind die erweiterten Wildcards außer Kraft gesetzt. Die Shell benutzt dann nur die Wildcards, die von TOS zur Verfügung gestellt werden. Das Programm für den Vergleich mit erweiterten Wildcards stammt von Rich Salz und wurde 1986 geschrieben. --------------------------------------------------------------------------- FLAGS UND PARAMETER Jedem Kommando können Flags und Parameter übergeben werden. I.d.R. werden Parameter benutzt, um festzulegen, womit etwas getan werden soll, und die Flags legen fest, wie es getan werden soll. Die Shell teilt die Eingabezeile in Worte auf. Worte werden durch White- space-Zeichen (Leerzeichen, Tab, Formfeed) getrennt. Durch doppelte (") oder einfache (') Anführungszeichen können auch Whitespace-Zeichen in Worten benutzt werden, z.B. ist a b c d vier Worte, während "a b c d" nur ein Wort ist. Einfache Anführungszeichen verhindern außerdem jede Art von Interpretation, d.h. innerhalb von einfachen Anführungszeichen werden * keine Shellvariablen expandiert * keine Slashes zu Backslash umgeformt * keine Escape-Sequenzen (beginnent mit ^) interpretiert * keine Command-Substitution ausgeführt . Es ergibt also $HOME den Inhalt der Shell-Variablen HOME und '$HOME' den String $HOME. Externen Kommandos werden alle übergebenen Flags und Parameter als Kommandozeile übergeben. Alle exportierten Shell-Variablen werden den externen Kommandos im Environment übergeben. Das Betriebssystem limi- tiert die Länge der Kommandozeile auf maximal 125 Zeichen. Die Über- gabe von mehr Zeichen ist durch das xArg-Protokoll möglich. Den internen Kommandos können beliebig viele Flags und Parameter übergeben werden, allerdings ist für die meisten Kommandos nur eine be- schränkte Anzahl von Parametern sinnvoll. Die Flags der internen Kommandos werden durch ein Minus- oder Plus- zeichen eingeleitet. Näheres siehe commands.doc. Die Shell benutzt eine Reihe eigener Flags, die mit dem internen Kom- mando set eingestellt werden können. Siehe hierzu commands.doc. ---------------------------------------------------------------------------- VERKETTETE KOMMANDOS Kommandos können in einer Zeile durch Semikolon getrennt angeführt werden. Die Kommandos werden von links nach rechts ausgeführt. Wenn eine eingegebene Zeile mit einem Dach (^) endet, wird anstelle des Daches die Fortsetzung der Zeile von der Sekundäreingabe eingelesen. Das entspricht dem Backslash in Unix. (In TOS ist der Backslash zum Trennen von Datei- und Ordnernamen reserviert.) Beispiel: ec^ ho ha^ l^ lo entspricht "echo hallo". Dabei kann diese Eingabe sowohl von der Tasta- tur als auch aus einem Shellscript oder einer Shellfunktion stammen. ---------------------------------------------------------------------------- SHELLVARIABLEN Eine besondere Art von internem Kommando ist die Zuweisung eines Wertes an eine Shellvariable. Alle Shellvariablen sind Stringvariablen. Der Name einer Shellvariablen kann in beliebiger Reihenfolge Buchstaben, Zif- fern und Underscores (_) enthalten. Beschränkungen: Maximalanzahl der Shellvariablen: 200 Maximallänge des Variablennamens und -Wertes: unbeschränkt (80 relevante Stellen) Wer damit nicht auskommt, benutze den Software-Support, um eine Versi- on der Shell mit größeren Kapazitäten zu erhalten. Die Maximalanzahl der Variablen einer Shell kann mit "ver -l" ermittelt werden. Jede Shell-Variable hat einen Status, der aus beliebigen (auch null) der folgenden Eigenschaften besteht: USR (User): Die Variable wurde vom Benutzer angelegt oder verändert. SYS (System): Es handelt sich um eine Systemvariable, die von der Shell verwaltet wird. Hierzu gehören z.B. die Positionsparameter $0, $1..., $#, $? usw. R/O (Read-Only): Der Wert der Variablen darf nicht verändert und die Variable darf nicht gelöscht werden. EXP (Export): Die Variable befindet sich im Environment. Die Eigenschaften USR und SYS können nicht beeinflußt werden. Die Ei- genschaften R/O und EXP können mit den Kommandos `readonly' und `export' gesetzt und gelöscht werden. Siehe hierzu commands.doc. DEKLARATION Shell-Variablen brauchen nicht deklariert zu werden. ZUWEISUNG Die Zuweisung eines Wertes an eine Shell-Variable geschieht durch eine Eingabe der Form Variable=Wert z.B.: NAME=Okami-Shell Es wird der String "Okami-Shell" der Shellvariablen NAME zugewiesen. In Unix ist es üblich, Shell-Variablen in Großbuchstaben zu schreiben, es sind allerdings auch Kleinbuchstaben möglich. NAME und Name sind zwei unterschiedliche Variablen. Auf die folgende Weise kann einer Variablen ein leerer Wert zugewiesen werden: Variable="" Der Wert der Variablen wird also gelöscht, aber die Variable selber bleibt bestehen. Außerdem können die internes Kommandos "read", "fsel", "alert" und "mouse" zur Zuweisung von Eingaben an Shellvariablen benutzt werden. Siehe hierzu commands.doc. BENUTZUNG Der Wert einer Shell-Variablen kann durch Angabe des Variablennamens mit vorgestelltem Dollar-Zeichen angegeben werden. In einer Eingabezeile der Shell werden erst alle Variablen zu den betreffenden Werten expan- diert, bevor die Zeile ausgeführt wird. Shell-Variablen, an die noch kein Wert zugewiesen wurde, werden als Leerstrings behandelt. Beispiele: NAME=Okami-Shell echo $NAME erzeugt die Ausgabe "Okami-Shell". NAME=Okami-Shell echo Der Name ist $NAME und nicht anders. erzeugt die Ausgabe "Der Name ist Okami-Shell und nicht anders." VAR1=$VAR2 weist der Variablen VAR1 den Wert der Variablen VAR2 zu. VAR1=VAR2 VAR3=VAR1 $VAR1=$VAR3 weist der Variablen VAR2 den String VAR1 zu (ja, wirklich.) Es ist auch möglich, Shell-Kommandos an Variablen zuzuweisen und dann ausführen zu lassen: CC=c:\compiler\cc.ttp $CC test.c ruft das Programm c:\compiler\cc.ttp mit dem Parameter test.c auf. LÖSCHEN Auf die folgende Weise werden Variablen gelöscht: Variable= Dies ist nicht zu verwechseln mit dem Löschen des Inhalts einer Varia- blen (siehe oben). Wenn hinter dem Gleichheitszeichen nichts steht, wird die Variable vollständig gelöscht und belegt danach keinen Platz mehr in der Variablentabelle. Dies ist notwendig, da die Shell nur über eine begrenzte Anzahl von Va- riablen verfügt. Besonders Shell-Scripts, die Variablen für lokale Zwecke benutzen, sollten diese Variablen nach der Benutzung wieder freigeben. Shellvariablen können außerdem mit dem Kommando unset gelöscht wer- den. Beim Löschen verliert die Variable natürlich auch ihren Status. Um den Status zu erhalten, darf nur der Wert der Variablen gelöscht werden (NAME=""). Beispiele: NAME= Die Shell-Variable NAME wird gelöscht. unset NAME Ebenso. SAVECWD=$CWD cd c:\work\test .......................(weitere Kommandos) cd $SAVECWD Das aktuelle Verzeichnis (das stets in der Variablen CWD steht) wird in der Variablen SAVECWD gesichert. Danach wird das aktuelle Verzeichnis geändert (mit dem internen Kommando "cd"), und es werden weitere Kommandos ausgeführt. Anschließend wird das aktuelle Verzeichnis wieder restauriert. Diese Technik sollte von allen Shellscripts benutzt werden, die das aktu- elle Verzeichnis ändern. Unter Unix werden Shellscripts stets von Sub- shells ausgeführt, und das aktuelle Verzeichnis ist eine Eigenschaft eines Prozesses, weswegen Shellscripts das aktuelle Verzeichnis ändern können, ohne das aktuelle Verzeichnis der aufrufenden Shell zu beeinflussen. Die Okami-Shell benutzt keine Subshells, und daher kann jedes Shell script das aktuelle Verzeichnis der Shell ändern, was in der praktischen Anwen- dung nicht immer erwünscht ist. Das umständliche Speichern und Restaurieren des aktuellen Verzeichnis- ses entfällt, wenn die Shell-Flags x und c gesetzt sind. Siehe hierzu das interne Kommando `set' in commands.doc. Es ist möglich, eine Shellvariable zu benutzen, deren Name nur aus ei- nem Underscore (_) besteht. Die Verwendung einer solchen Variablen für kurzzeitige lokale Verwendungen ist z.B. in der Programmiersprache Pro- log üblich. SYSTEMVARIABLEN Eine Reihe von Shellvariablen werden von der Shell selber angelegt und benutzt. Es ist teilweise möglich, die Werte dieser Variablen zu verän- dern. Die Systemvariablen sind: OKSH_PROFILE Das beim Start der Shell zu landende Profile. Muß folglich bereits beim Start der Shell im Environment vorhanden sein und hat von da an keine Bedeutung für die Shell mehr. PS1 Das Eingabeprompt. Kann vom Anwender verändert werden (was normalerweise im Profile geschieht). Der Defaultwert ist " $ ". PS2 Das sekundäre Eingabeprompt. Erscheint z.B. bei der Eingabe von Shellfunktionen. Kann beliebig verändert werden, der Defaultwert ist "> ". OKAMISHELL Die Versionsnummer der Shell. Kann nicht verändert werden. Diese Variable wird nicht an gestartete Programme weitergegeben und ist deshalb nur in Shellscripts gesetzt, wenn diese unter der Okami-Shell laufen. Daher kann das Vorhandensein dieser Variablen als Test benutzt werden, ob ein Shellscript unter der Okami- oder einer anderen Shell ausgeführt wird. TERM Der Rechnertyp, wird anhand des _MCH-Cookies eingestellt und ist je nachdem "Atari ST", "Atari Mega ST", "Atari STE" oder "Atari TT". Wenn kein Cookie-Jar installiert ist, wenn kein _MCH-Cookie vorhanden ist oder wenn dessen Wert kleiner als 0 oder größer als 3 ist, wird "Atari ST" benutzt. TERM ist in der jetzigen Version der Shell noch ohne weitere Bedeutung, wird aber von einigen Program- men benutzt, die eine Unix-ähnliche Termcap verwenden (z.B. Gnu- Emacs) und sollte dann auf den entsprechenden, von der Termcap benötigten Wert eingestellt werden. CWD Das aktuelle Verzeichnis. Wird nach jedem Wechsel des Verzeich- nisses automatisch aktualisiert und sollte nicht von Hand verändert werden. (Durch eine Zuweisung an diese Variable wird das aktuelle Verzeichnis NICHT geändert.) HOME Das Verzeichnis, aus dem die Shell gestartet wurde (genauer gesagt das aktuelle Verzeichnis zum Zeitpunkt des Starts der Shell). Kann nach Bedarf verändert werden. ETC Das Verzeichnis, in dem die Shell Hilfsdateien wie z.B. die Textda- tei für das help-Kommando erwartet. Wird bei Programmstart auf denselben Wert wie HOME eingestellt und kann beliebig verändert werden. SHELL Hier soll der vollständige Aufrufpfad des Shellprogramms eingetragen sein. Da die Shell diesen nicht mit völliger Sicherheit selber bestim- men kann, wird hier $HOME\sh.ttp eingetragen. Kann beliebig ange- paßt werden, wenn diese Angabe einmal nicht zutrifft. Wird nicht von der Shell, aber von einigen Programmen benutzt (z.B. Micro- Emacs oder Pure C). Wer ein neues Programm schreibt, sollte die Shell lieber über den _shell_p-Zeiger aufrufen. PAGELEN Die Anzahl der Zeilen auf dem Bildschirm. Wird von dem internen Kommando pg (bzw. more) benutzt. Kann beliebig eingestellt wer- den. Die Defaulteinstellung ist 23. PIPDIR Das Laufwerk und der Pfad, auf dem die Hilfsdateien von Pipelining, Command Substitution usw. erzeugt werden. Muß auf einem be- schreibbaren Laufwerk (am besten auf einer Ramdisk) liegen. Die Defaulteinstellung ist $HOME. Kann beliebig verändert werden. NULL Der Name des Gerätes oder der Datei, an die die Ausgaben geleitet werden, die zum Null-Gerät (NULL:) umgeleitet werden. Kann ver- ändert werden. Die Defaulteinstellung ist "PRN:" (paralelle Schnitt- stelle). Wer einen Drucker hat, sollte hier eine Datei z.B. auf der Ramdisk eintragen. Die Einstellung AUX: für die serielle Schnittstel- le ist nicht möglich, da diese Schnittstelle von der Standard-Fehler- ausgabe belegt ist. XEXT Eine Liste von durch Kommata oder Semikolons getrennten Exten- dern. Dateien mit einem der hier aufgeführten Extender können als Binärprogramme gestartet werden. Die Defaulteinstellung ist ".prg,.tos,.ttp,.app". Die Punkte vor den Extendern müssen mit angege- ben werden. Kann beliebig verändert werden. SEXT Eine Liste von durch Kommata oder Semikolons getrennten Exten- dern. Dateien mit einem der hier aufgeführten Extender können als Shellscripts gestartet werden. Die Defaulteinstellung ist ".sh". Die Punkte vor den Extendern müssen mit angegeben werden. Kann be- liebig verändert werden. GEXT Eine Liste von durch Kommata oder Semikolons getrennten Exten- dern. Binärdateien mit einem der hier aufgeführten Extender werden als GEM-Programme, d.h. nicht direkt, sondern über die Shellfunkti- on gemexec gestartet. Siehe hierzu den Abschnitt über gemexec in commands.doc. Die Defaulteinstellung ist ".prg". Kann beliebig verän- dert werden. Wie in commands.doc erklärt, müssen die Extender nicht unbedingt denen von ausführbaren Programmdateien entsprechen. MANEXT Eine Liste von durch Kommata oder Semikolons getrennten Exten- dern. Dateien mit einem der hier angeführten Extender werden von der Online-Hilfe mit der Helptaste oder dem Kommando man als Anleitungsdateien erkannt. Die Voreinstellung lautet ".doc,.man". Kann beliebig verändert werden. PATH Eine Liste von durch Kommata oder Semikolons getrennten Pfaden. Bei der Eingabe eines externen Kommandos ohne vollständige Pfad- angabe wird die Datei auf den hier angegebenen Pfaden gesucht. Die Defaulteinstellung ist ".,..,$HOME,$HOME\bin". Kann beliebg ver- ändert werden. CDPATH Eine Liste von durch Kommata oder Semikolons getrennten Pfaden. Beim Wechsel des aktuellen Arbeitsverzeichnisses mit "cd" wird, wenn der bei cd angegebene Pfad nicht existiert und nicht absolut angegeben ist, auf den in CDPATH gespeicherten Pfaden gesucht. Die Defaulteinstellung ist "..,\". Kann beliebig verändert werden. MANPATH Eine Liste von durch Kommata oder Semikolons getrennten Pfaden. Auf diesen Pfaden sucht die Online-Hilfe (Helptaste oder das Kom- mando man) nach Anleitungsdateien. Die Defaulteinstellung ist "$HOME/doc". Kann beliebig verändert werden. HELPFILE Der Name der Datei, aus der die Erklärungen, die bei Druck auf die Help-Taste ausgegeben werden, stehen. Die Default einstellung ist "$HOME\doc\commands.doc". Kann beliebig verändert werden. CLIPDIR Enthält den Pfad des GEM-Clipboards. Wird durch die Kommandos gon und clipb initalisiert, die Voreinstellung bei Programmstart lautet "X:\scrapdir\scrap.*", wobei X: das Bootlaufwerk ist. Diese Shellvari- able sollte nur mit dem Kommando clipb verändert werden. Siehe hierzu auch commands.doc. 0 Enthält bei Eingabe eines Kommandos den Namen des Kommandos und beim automatischen Aufruf der Funktion gemexec den vollstän- digen Pfad des aufzurufenden Programms. 1 Enthält den ersten Parameter der Eingabezeile. 2 Enthält den zweiten Parameter der Eingabezeile usw. # Enthält die Anzahl der Parameter der Eingabezeile. * Enthält die vollständige Eingabezeile. ? Enthält den Rückgabewert des zuletzt ausgeführten Kommandos. Die folgenden Shellvariablen werden nur von einzelnen internen Komman- dos benutzt. COLUMNS von `scr': Anzahl der Zeilen auf dem Bildschirm. DIALPREFIX für `dial': Präfix des Modem-Wählkommandos. Nach dem Start der Shell werden Variablendefinitionen aus dem Environ- ment gelesen und ausgeführt. Auf diese Weise können alle Variablen (auch LOGNAME usw.) geändert, aber keine gelöscht werden. ---------------------------------------------------------------------------- EIN/AUSGABE-UMLEITUNG 1) Für interne Kommandos Die Eingabe, Ausgabe und Fehlerausgabe jedes internen Kommandos kann auf einfache Weise in bzw. aus einer beliebigen Datei oder zu bzw. von einem Gerät umgeleitet werden. Folgende Umleitungsmöglichkeiten stehen zur Verfügung: < Datei Umleitung der Eingabe > Datei Umleitung der Ausgabe, die Datei wird vorher gelöscht >> Datei Anhängen der Ausgabe an die Datei 2> Datei Umleitung der Fehlerausgabe, die Datei wird vorher gelöscht 2>> Datei Anhängen der Fehlerausgabe an die Datei Anstelle von "Datei" können auch die folgenden Geräte angegeben sein: CON: Konsole (Default) PRN: parallele Schnittstelle (Drucker) AUX: serielle RS232-Schnittstelle (Modem) NULL: ignorieren Das Gerät NULL:, auch Null-Gerät genannt (in Unix: /dev/null), wird nicht vom Betriebssystem des ST unterstützt, sondern von der Shell simu- liert. Der Zweck eines Null-Gerätes ist, die Ausgabe oder Fehlerausgabe eines Kommandos zu unterdrücken. Die Shell-Variable NULL gibt an, wo die Ausgabe, die an NULL: umgeleitet wird, tatsächlich landen soll. Nor- malerweise ist das die Druckerschnittstelle; wenn diese von einem Druk- ker belegt ist, sollte man eine reguläre Datei z.B. auf der Ramdisk ange- ben (NULL=G:/null). Beispiel: rm *.dup löscht sämtliche dup-Dateien, gibt aber eine Fehlermeldung aus, wenn keine solchen Dateien vorhanden sind oder wenn sie schreibgeschützt sind. Um die Fehlermeldung zu unterdrücken, kann man stattdessen schreiben: rm *.dup 2>NULL: Dadurch werden die Fehlermeldungen an das Null-Gerät geleitet. (Nebenbei: bei Verwendung von rm -f *.dup werden auch keine Fehlermeldungen ausgegeben, allerdings werden damit auch schreibgeschützte Dateien gelöscht.) Wenn keine Umleitung angegeben ist, geht die Eingabe von der Tastatur und die Ausgabe und Fehlerausgabe zum Bildschirm, genauer gesagt zu der Standard-Ein- und -Ausgabe der Shell selber (die beim Start von sh.ttp angegeben werden kann). PIPELINING Die Idee des Pipelining ist es, die Ausgabe eines Kommandos zur Einga- be des nächsten zu machen. So schreibt z.B. das memex-Kommando ei- nen Speicherbereich auf seine Ausgabe, und das hd-Kommando fertigt von seiner Eingabe ein Hexdump an. Mit dem Pipelining können beide Kom- mandos verbunden werden, d.h. man bekommt ein Hexdump eines Spei- cherauszuges. Um zwei Kommandos in einer Pipeline zu verbinden, wird zwischen sie ein senkrechter Strich (|), auch Pipe genannt, gesetzt, z.B.: hd sh.ttp | pg Die Ausgabe des hd-Kommandos (ein langer Hexdump) wird zur Eingabe des pg-Kommandos, wodurch der Hexdump seitenweise angezeigt wird. Die Schreibweise a | b ist äquivalent zu: (a und b sind beliebige Kom- mandos incl. ihren Parametern) TMP=$PIPDIR\pip$$ a > $TMP chmod +h $TMP b < $TMP rm $TMP unset TMP (mit drei kleinen Unterschieden: 1) zum Bilden eines eindeutigen Dateina- mens wird nicht $$, sondern ein anderer Zähler benutzt, 2) die Datei wird nach dem Anlegen und nicht erst nach dem Ende von a unsichtbar gemacht und 3) es wird keine Shellvariable benutzt.) Dies ist ein wesentlicher Unterschied zu Unix, wo alle an einer Pipe be- teiligten Kommandos (Prozesse) gleichzeitig laufen. Eine Pipeline ist unter Unix eine Einrichtung des Betriebssystems, die von der Okami-Shell nur simuliert wird. (Wie gesagt, Okami ist eine Shell und kein Betriebssys- tem.) Das Laufwerk und der Ordner, auf dem die Pipe-Dateien erzeugt werden, kann mit der Shellvariablen PIPDIR eingestellt werden. Die Defaulteinstel- lung beim Start der Shell ist $HOME. Dadurch bietet sich die Möglich- keit, die Pipe-Dateien auf ein schnelles Laufwerk zu legen, z.B. auf eine Ramdisk oder eine wenig benutzte Partition der Festplatte. VORSICHT: Wenn $PIPDIR auf einen nicht existierenden Ordner oder Laufwerk eingestellt ist, erscheinen anstelle von Pipe-Operationen nur Fehlermeldungen der Form: Error: cannot open .....\pip3 (Anstelle von ...... steht der Inhalt von PIPDIR.) In diesem Fall wird keins der an einer Pipe beteiligten Kommandos aus- geführt. Abhilfe schafft das Kommando mkdir -r $PIPDIR/ im Profile nach dem Einstellen von PIPDIR. Dadurch werden alle zu $PIPDIR gehörenden Unterverzeichnisse erzeugt. Die Pipe-Datei kann mit folgendem Kommando sichtbar gemacht werden: ls -a $PIPDIR\pip* | cat INLINE-DOKUMENTE Als Inline- oder Hier-Dokument wird eine spezielle Art der Eingabeumlei- tung bezeichnet, bei der die einem Kommando zuzuführende Eingabe di- rekt von der Eingabe oder z.B. dem Shellscript stammt. Beispiel: cat <<eof Das ist ein Text, der zu der Eingabe des cat- Kommandos wird. eof Diese Zeilen können von der Tastatur eingegeben, aber auch in einem Shellscript oder einer Shellfunktion stehen. Die Shell betrachtet die Zeichenkette nach "<<" als Terminierungsstring und schreibt die nachfolgenden Zeilen in eine Datei, die dann als Eingabe des Kommandos benutzt wird. Das Inline-Dokument wird durch eine Zeile beendet, die nur (bis auf führende Leerzeichen) aus dem Terminierungs- string besteht. Wenn den << direkt ein Minuszeichen folgt, also z.B. cat <<-eof , werden alle führenden Leerzeichen der Eingabezeilen entfernt. Das Mi- nuszeichen gehört nicht zu dem Terminierungsstring. Die Shell führt auf allen eingelesenen Zeilen Variablensubstitutionen und Command Substitution aus. Inline-Dokumente sind sinnvoll in Shellscripts, die mehrzeilige Ausgaben erzeugen sollen, wodurch sich Reihen von echo-Kommandos vermeiden lassen. 2) Für externe Kommandos Theoretisch funktionieren sämtliche Ein/Ausgabe-Umleitungen inklusive der Pipeline auch mit externen Kommandos. In der Praxis jedoch erlauben nicht alle Programme diese Möglichkeit, z.B weil sie Tastatur und Bild- schirm direkt über die entsprechenden Bios-Funktionen (Bconout etc.) an- sprechen, die sich nicht umleiten lassen. Die Okami-Shell leitet die Ein/Ausgabe auf Gemdos-Basis um, was bedeu- tet, daß alle Programme, die für die Ein/Ausgabe Gemdos-Funktionen (Cconout etc.) benutzen, umgeleitet werden können. C-Programme, die die Standard-Streams stdin und stdout benutzen, werden normalerweise kor- rekt umgeleitet. GEM-Programme sind von vornherein gegen jede Art der Umleitung im- mun, da sie den Bildschirm über den entsprechenden GEM-Gerätetreiber ansprechen. ---------------------------------------------------------------------------- COMMAND SUBSTITUTION Die Okami-Shell bietet die Möglichkeit, die Ausgabe eines Kommandos in eine Kommandozeile einzubauen. Möchte man z.B. eine Ausgabe wie "Es sind ... Bytes frei" erzeugen, in die die Anzahl der freien Bytes (die mit dem Kommando mem ermittelt werden kann) eingebaut sind, dann kann die Ausgabe von mem auf folgende Weise in das echo-Kommando einge- baut werden: echo Es sind `mem` Bytes frei. Alles, was in einer Eingabezeile zwischen zwei Accent grave (`) steht, wird als Kommando betrachtet und ausgeführt. Die Ausgabe wird anstelle der in Accent grave stehenden Zeichenkette in die Eingabezeile einge- setzt. Dieses Verfahren wird als Command Substitution bezeichnet. Wenn die Ausgabe des Kommandos über mehrere Zeilen geht, wird nur die erste Zeile (also die Ausgabe bis zum ersten Zeilenende) benutzt. Als Zwischenspeicher für die Ausgabe des Kommandos wird eine Datei namens $PIPDIR/csubXXXX benutzt. XXXX ist hierbei eine laufende Nummer, und $PIPDIR ist das Laufwerk, über das auch die Pipelining- Operationen laufen. Diese Datei wird nach Verwendung gelöscht. Beispiele: Speichern der Shellflags: SET=`set -` Wiederherstellen mit: set $SET Anzeigen einer Datei, die in demselben Ordner liegt wie $FILE1, die aber denselben Basisnamen wie $FILE2 hat: cat `dirname $FILE1`/`basename $FILE2` Löschen der ältesten Datei mit Nachfrage: rm -i `ls -t` ---------------------------------------------------------------------------- ENVIRONMENT Die Okami-Shell bietet die Möglichkeit, Definitionen von Shell-Variablen in das Environment zu übernehmen. Diese Definitionen werden dann allen gestarteten Programmen übergeben. Mit dem internen Kommando export können beliebige Shellvariablen in das Environment ausgenommen oder daraus entfernt werden. In der Basepage eines Programms steht ab Offset 0x2c die Adresse des Environment-Strings. Diese Adresse wird berechnet als: char *BaseAdr; char *EnvAdr; EnvAdr = *(char **)(BaseAdr+0x2c); BaseAdr ist die Adresse der Basepage (wird irgendwie vom Compiler zur Verfügung gestellt). EnvAdr ist dann die Adresse des Environment-Strings. Dieser String hat folgende Syntax: EnvString ::= { VarDefinition } "\0" VarDefinition ::= VarName "=" VarWert "\0" Beispiel: "a=Variable a\0b=Variable b\0usw=undsoweiter\0\0" Es werden folgende Variablen gesetzt: a auf "Variable a" b auf "Variable b" usw auf "undsoweiter" ---------------------------------------------------------------------------- GRÜSSE 1) An die Firma GRP in Aachen, für lebenswichtige Kenntnisse in C und Unix. 2) Für die Begleitung in zahllosen Stunden voller Lust und Frust vor der flimmerfreien Flimmerkiste: Mike Oldfield, The Beatles, Little Richard, Bill Haley, Tommy Roe, Lesley Gore, Pat Boone, Elvis Presley, Chuck Berry, Del Shannon, Chris Montez, Billy Joe Roy- al, The Box Tops, The Cascades, Trini Lopez, Chris Andrews, Mary Hopkins, The Tremoloes, Bobby Vee, The Kinks, The Turtles, The Swinging Blue Jeans, Shane Fenton & The Fentones, The Piltdown Men, Helen Shapiro, Cliff Richard, The Cowsills, Jerry Lee Lewis, Melanie, Buddy Hollie, The Lovin' Spoonful, The Cry- stals, The Knickerbockers, The Crests, Every Mother's Son, The Shangri Las, Ber- nard Cribbins, The Shadows, Frank Ilfield u.v.a. Diese Anleitung wurde mit Tempus Word von CCD erstellt. Atari ST, GEM, Unix, MS-Dumpf usw. sind eingetragene Warenzeichen von - ach das wißt Ihr schon? Na gut.