SPACE 2

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

/ SPACE 2 / SPACE - Library 2 - Volume 1.iso / program / 522 / okami12 / doc / tricks.doc < prev next >

Wrap

Text File | 1991-04-17 | 26.2 KB | 815 lines

=============================================== @(#) OKAMI SHELL VERSION 1.2 - TIPS UND TRICKS =============================================== Stand: 22.12.90 BITTE ERST DIE DATEIEN README UND OKAMI.DOC LESEN! ---------------------------------------------------------------------------- INHALT Profile Aufruf von Programmen Benutzung der Shell von Diskette aus Beispiel-Shellscripts oksave.sh e.sh showpic.sh startprg.sh Shell-Funktionen Die gemexec-Funktion Die screensave-Funktion MS-DOS-Gefühle C-Shell-Gefühle Gulam-Shell und Master Die Versionsnummer der Shell Diverses Trikolor-Bildschirm Aufruf vom Desktop Zweideutige Kommandonamen Compiler-Aufruf Ändern von Dateinamen-Extendern ---------------------------------------------------------------------------- PROFILE Ich benutze das folgende Profile zum Konfigurieren der Shell im Festplatten- betrieb. # Okami-Shell - System-Profile TERM=Atari 1040 STF # Cursor etwas schneller blinkend cursor +bv 12 # Aktuelles Directory im Prompt anzeigen PS1=['$CWD'] ^^^$' ' # Pipes auf der Ramdisk PIPDIR=g:\ # Nach Ende der Shell CWD sichern... set +s # ...und den Cursor abschalten trap cursor -v # Directories trennen wie in Unix mit Slash set +b # anmelden als Applikation, stört ja nicht gon # Word Wrap On echo ^033v # Bidschirm löschen durch viele Leerzeilen, Cursor steht dann unten echo "^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n^n" # Einschaltmeldung echo echo $TERM # Versionsnummer der Shell, des TOS und von MiNT (falls vorhanden) ver -otM echo # Ausgabe des Datums des letzten Logins cat lastlog 2>NULL: echo # Ausgabe des freien Speichers echo Free RAM: `mem` Bytes echo # Ausgabe in invertierter Schrift echo ^033pType help for command survey.^033q echo # Datum speichern echo Last Login: `date` >lastlog # Letztes CWD zurückholen cd `cat wdir` Laufwerk G ist eine Ramdisk (Luftschloß 32K), die die einzige Aufgabe hat, die Pipe-Operationen zu beschleunigen. Dadurch, daß die Pipe auf die Ramdisk gelegt wird (PIPDIR=g:\), erfolgen alle Pipe-Operationen ohne Platten- zugriff. Durch die Einstellung "set +s" wird die Shell veranlaßt, vor dem Programm- ende das aktuelle Verzeichnis in die Datei $HOME\wdir zu schreiben. Das Profile benutzt diese Datei, um das aktuelle Verzeichnis wieder auf den alten Wert einzustellen. So ist man nach dem Start der Shell immer in dem Verzeichnis, in dem man war, als man die Shell zuletzt verlassen hatte. Durch die Einstellung "set +x" werden in einer Eingabe alle Slashes (/) in Backslashes (\) umgeformt, wodurch man die Möglichkeit hat, Dateinamen wie in Unix einzugeben, also shell/bin/sh.ttp anstatt shell\bin\sh.ttp. Natürlich erzeugt dann das Kommando echo 6/3=2 die Ausgabe 6\3=2 da alle Slashes umgeformt werden, aber das stört normalerweise nicht. (den UPN-Rechner stört es übrigens auch nicht, da er den Backslash als Divisionszeichen versteht. Aus "upn 6 3 /" wird also "upn 6 3 \".) Außerdem kann man sich in Notfällen mit einfachen Anführungszeichen retten, echo '6/3=2' ergibt also immer 6/3=2 . ---------------------------------------------------------------------------- AUFRUF VON PROGRAMMEN (Der folgende Abschnitt ist im wesentlichen für Festplattenbenutzer von Interesse.) Viele Programme gehen davon aus, das sich gewisse Dateien wie z.B. RSCs im aktuellen Verzeichnis befinden. Um ein solches Kommando zu starten, muß man also mit cd in das jeweilige Verzeichnis wechseln, was unter Umständen einige Tipparbeit macht, vor allem bei einer Festplatte. Mit der Okami- Shell ist es möglich, Programme von überall, also von jedem beliebigen aktuellen Verzeichnis aus zu starten. Es sei z.B. GEMTEST.PRG ein Programm, das im Verzeichnis D:\PROG\GEMTEST steht und eine RSC-Datei aus dem aktuellen Verzeichnis nachladen muß. Zum Start des Programms müßte man also eingeben cd d:\prog\gemtest gemtest Man kann allerdings auch so vorgehen: Man erzeugt sich eine Datei namens GEMTEST.SH im Verzeichnis $HOME\bin, die ungefähr so aussieht: a=`set -` set +x d:\prg\gemtest\gemtest.prg set $a a= Zuerst wird der augenblickliche Zustand der Shellflags in der Variablen a gespeichert, danach wird das Flag x aktiviert. Wenn dieses Flag akti- viert ist, führt die Shell vor dem Start eines Binärprogramms ein cd in das Directory aus, in dem sich das Programm befindet. Nach dem Ende des Programm wird das ursprüngliche Directory wieder restauriert. Danach wird das Programm gestartet. Nach Programmende werden die Shell-Flags werden auf den gespeicherten Wert zurückgesetzt. Danach wird die lokal verwendete Shellvariable a freigegeben. Dadurch, daß sich dieses Shell-Script in dem Verzeichnis $HOME\bin befin- det, kann es jederzeit durch einfache Eingabe von gemtest aufgerufen werden. Man kann es dann auch mit "($HOME\bin\gemtest.sh)" resident als Shellfunktion laden, dann spart man sich bei jedem Aufruf das Laden des Scripts. Normalerweise ist das Flag x immer aktiviert. Programme, die sich in einem der in der Shellvariablen PATH gespeicherten Directories befinden, werden also immer korrekt gestartet, indem man nur ihren Namen eingibt. ---------------------------------------------------------------------------- BENUTZUNG DER SHELL VON DISKETTE AUS Wenn möglich, sollte man die Shell auf einem schnellen Massespeicher wie Festplatte oder Ramdisk installieren. Wer die Shell hauptsächlich mit Disketten benutzt, ärgert sich vermutlich darüber, daß es ziemlich lange dauert, bis ein falsch eingetipptes Kommando als solches erkannt wird, da die Shell in allen möglichen Ordnern auf der Diskette nach einer passenden Datei sucht. Mit den folgenden Einstellungen im Profile kann die Anzahl dieser Suchoperationen minimiert werden: PATH=.,$HOME\bin CDPATH=. Wenn man den Programm-Suchpfad auf das aktuelle Directory abkürzt (mit der Einstellung "PATH=."), werden noch weniger Suchoperationen durchgeführt, man kann dann allerdings die mitgelieferten externen Kommandos, die sich in dem Directory $HOME/bin befinden sollten, nicht mehr von überallher durch den einfachen Kommandonamen aufrufen, sondern muß den ganzen Pfad angeben (z.B. nicht einfach "format", sondern "$HOME\bin\format.ttp"). ---------------------------------------------------------------------------- BEISPIEL-SHELLSCRIPTS 1) oksave.sh Ich benutze das folgende Shellscript namens oksave.sh zum Sichern der Quelldateien der Shell auf Diskette. DEST=$1 if [ -v DEST ] echo Verwendung: oksave Directory exit fi if [ -d $DEST ] else echo Ein Directory namens $DEST existiert nicht, anlegen? (j/n) read b if [ -v b ] b=n fi if [ $b = j ] mkdir $DEST b= else b= exit fi fi echo ^nSichern der Okami-Files auf $DEST ^n a=$CWD cd e:\okami backup -r $DEST <files.lst b=`date` c=`drvname $DEST` echo $b: Okami-Sources gesichert auf $DEST >>oklog echo $b: Okami-Sources gesichert auf $DEST >>$c/oklog echo Sichern beendet. cd $a DEST= a= b= c= Das aktuelle Directory wird in einer Shellvariablen gespeichert und dann auf e:\okami (wo sich die Quellen befinden) umgestellt. Dort befindet sich ebenfalls eine Datei namens files.lst, in der die Namen aller zu sichernden Dateien stehen. Diese Datei wird als Eingabe für das Backup- Kommando benutzt, das alle Dateien auf Diskette sichert, und zwar in den Ordner, der beim Aufruf des Scripts als Parameter angegeben wird ($1). Danach werden Datum und Uhrzeit des Sicherns in eine Datei namens oklog sowohl im Wurzelverzeichnis der Diskette als auch in e:\okami geschrieben. Diese Datei wächst, d.h. die Angaben werden an die Datei angehängt, so daß sie die Daten aller Sicherungen enthält. Danach wird das aktuelle Laufwerk wiederhergestellt und die verwendeten Shellvariablen freigegeben. Hier ein Auszug aus der Datei files.lst: # Okami-Shell-Dateien zum Sichern auf Diskette # Quellen sh.c cmds.c cmds2.c utl.c utl2.c okami.h okext.h # ausführbare Dateien sh.ttp msh.prg gem.prg 2) e.sh Das Shellscript e.sh dient zum Aufruf des Editors. Das Editorprogramm be- findet sich in der Datei $HOME\bin\editor.prg. Durch die Verwendung dieses Shellscripts ist es möglich, irgendwo im Dateisystem den Editor für irgend- eine Datei aufzurufen. FILE=$* if [ -v FILE ] then FILE=$EFILE fi FILE=`fullname $FILE` $HOME\bin\editor.prg $FILE EFILE=$FILE FILE= Der Name der zu editerenden Datei wird dem Script als Parameter übergeben. Die Zeile "FILE=`fullname $FILE`" erzeugt in der Variablen FILE den absoluten Dateinamen, der dem Editorprogramm als Parameter übergeben wird. Wenn dieses Script ohne Parameter aufgerufen wird, so wird der in der Shell- variablen EFILE gespeicherte Dateiname benutzt. In dieser Variablen wird nach jedem Editoraufruf der jeweilige Dateiname gespeichert, so daß man, wenn man dieselbe Datei mehrmals hintereinander editieren möchte, den Datei- namen nur einmal angeben muß: e datei.txt editieren von datei.txt e datei2.txt editieren von datei2.txt e ebenfalls datei2.txt Ggfs. muß man dieses Script noch erweitern, um dem Editor mehrere Parameter zu übergeben (für den Micro-Emacs z.B. den Namen der Konfigurationsdatei o.ä.). 3) showpic.sh Dieses Script zeigt, wie man die Shell programmieren kann. Es dient dazu, Bilddateien, die im Bitmap-Screenformat abgespeichert wurden (Dateilänge >32000 Bytes), zu laden und anzuzeigen. Es gehört zum Lieferumfang der Shell, die Bedienungsanleitung befindet sich in commands.doc. 4) startprg.sh Die Idee zu diesem Shellscript stammt von Thomas Behrens aus Eschweiler und lautet, ein Programm in einer Fileselectbox auszuwählen und dann zu starten. Dazu genügt eigentlich die folgende Zeile: fsel | xargs {} , wenn man aber den Abbruch-Button der Box abtesten und dem Programm eine Parameterzeile übergeben will, sollte man folgendes Script benutzen: FILE=`fsel *.* "" KEY` if [ $KEY = 1 ] then echo "Bitte Kommandozeile eingeben:" read CMD $FILE $CMD fi FILE= KEY= CMD= Beide Lösungen funktionieren übrigens sowohl mit Binärprogrammen als auch mit Shellscripts. --------------------------------------------------------------------------- SHELL-FUNKTIONEN Natürlich sollte man alle häufig gebrauchten Shellscripts resident halten, und zwar als Shellfunktionen. Es ist möglich, ein Shellscript so zu schreiben, daß es sich beim ersten Aufruf selber als Funktion installiert; bei allen weiteren Aufrufen wird dann die Funktion benutzt. Sei z.B. folgendes Shellscript in der Datei hallo.sh, also unter dem Namen hallo aufzurufen: echo Hallo Anwender! echo Der freie Speicherplatz beträgt `mem` Bytes. echo Der Platz auf Platte C: beträgt df C: Setzt man nun die Zeilen hallo() { an den Beginn und die Zeilen } hallo an das Ende dieses Scripts, also so: hallo() { echo Hallo Anwender! echo Der freie Speicherplatz beträgt `mem` Bytes. echo Der Platz auf Platte C: beträgt df C: } hallo so wird beim Start des Scripts die Shellfunktion hallo installiert, und bei jedem weiteren Aufruf von hallo wird nicht das Script, sondern die Funktion aufgerufen. Mit den zwei Zeilen hallo() {} kann man die Funktion wieder aus dem Speicher entfernen. Die Shellfunktionen machen übrigens eine alias-Funktion völlig überflüssig, da sie auch benutzt werden können, um interne Kommandos umzudefinieren: Wer anstelle von ls lieber ls -C hat, gibt einfach ein ls() { !ls -C $* } Wer irgendwann das normale ls benutzen will, kann das tun, indem er es als !ls aufruft. Ebenso helfen Shellfunktionen, Tippfehler zu vermeiden; wer ständig dor oder dior statt dir tippt, versuche dior() { dir $* } Mein Unix-Tippfehler-Script enthält mehrere Dutzend Schreibweisen der häufig benutzten Kommandos wie dir, grep und der Make-Aufrufe xmake, qmake und remake. Besondere Funktionen haben die vordefinierten (aber vom Anwender vollständig umdefinierbaren) Shellfunktionen gemexec und screensave, die im folgenden Abschnitt beschrieben werden. --------------------------------------------------------------------------- DIE GEMEXEC-FUNKTION Mit der kann man wirklich einiges machen, denn sie gibt dem Anwender die Möglichkeit, das Verhalten der Shell beim Start von GEM-Programmen frei zu programmieren. Dabei stehen ihm alle die nicht zu unterschätzenden Funktionen der Shell zur Verfügung. Die folgende Version ist eine Erweiterung der in commands.doc angeführten gemexec-Funktion, die vor dem Start eines GEM-Programms den Bildschirminhalt speichert und ihn nachher wiederherstellt. Da das 32000 Bytes an lokalen Speicher braucht, können Leute mit kleinem Speicher folgende Version benutzen, die den Bildschirm nur dann speichert, wenn die Shellvariable SAVESCR ge- setzt ist. Wenn diese Variable nicht gesetzt ist, verhält sie sich wie die Standardversion. Man kann das Speichern also mit SAVESCR=1 ein- und mit SAVESCR= wieder ausschalten. gemexec() { _=$0 if [ +v SAVESCR ] then echo ^033j^c getscr fi cls cursor -v exec -g $_ if [ +v SAVESCR ] then putscr putscr -f echo ^033k^c cursor +v else cls fi _= } --------------------------------------------------------------------------- DIE SCREENSAVE-FUNKTION Wenn in der Eingabe Control-P gedrückt wird, ruft die Shell die Shellfunktion screensave auf. In der Voreinstellung wird dadurch die normale Drucker-Hard- copy ausgelöst (was sinnvoll ist, wenn die Tastenkombination Alt-Help von einem residenten Programm okkupiert ist), aber durch Ändern der screensave- Funktion kann der Anwender jede beliebige Operation durch Ctrl-P auslösen lassen. Die folgenden drei screensave-Funktionen dienen dazu, die Hardcopy ähnlich dem Snapshot-Programm in eine Datei umzuleiten. Die erste Version fragt den Anwender mit einer Fileselect-Box nach dem Datei- namen. Diese Funktion geht davon aus, daß gon aktiviert ist. Alle Versionen stellen während des Speicherns den Cursor auf nichtblinkend und schalten ihn, wenn die Shell wieder zur Eingabe bereit ist, wieder auf blinkend zurück. Wer das nicht will, läßt die cursor-Aufrufe weg. screensave() { # Cursor nicht blinkend cursor -b # Bildschirm sichern getscr # nach einem Dateinamen fragen fsel *.pic "" KEY | read FILE # Abbruch geklickt? if [ $KEY = 1 ] then # nein, in die Datei speichern putscr -s $FILE fi # Speicher und Variablen freigeben putscr -f KEY= FILE= # Cursor wieder blinkend cursor +b } Die zweite Version verhält sich eher wie das Snapshot-Kommando. Sie baut selber einen Dateinamen zusammen. Der Dateiname ist "screen.", der Extender eine laufende Nummer. Der Zähler befindet sich in der Shellvariablen _SCRCOUNT, aufwärtsgezählt wird mit Hilfe des UPN-Rechners. screensave() { cursor -b getscr if [ -v _SCRCOUNT ] then # Wenn es die Zählvariable noch nicht gibt, bei 0 anfangen _SCRCOUNT=0 else # ansonsten 1 addieren. upn %ld $_SCRCOUNT ++ | read _SCRCOUNT # Das Ergebnis lassen wir nicht auf dem Stack rumliegen... upn pop fi # wie oben. putscr -s screen.$_SCRCOUNT putscr -f cursor +b FILE= } Die dritte Version fragt den Anwender, ob er die Hardcopy in eine Datei oder auf den Drucker haben möchte. screensave() { # Zuerst den Bildschirmspeicher sichern cursor -b getscr # Dann den Anwender fragen echo 'Bildschirm speichern: (D)rucker oder (F)ile?' read A if [ $A = D ] then # Druckerausgabe, dazu den Bildschirm wieder so herrichten, # wie er vor dem echo war putscr hardcopy fi if [ $A = F ] # Datei ................. (wie eins der beiden obigen Beispiele) fi # Speicher freigeben putscr -f A= cursor +b } Man kann das natürlich beliebig weit treiben und ein komplettes Menüprogramm schreiben, daß mit Ctrl-P aufgerufen wird. --------------------------------------------------------------------------- MS-DOS-GEFÜHLE Die Unverbesserlichen, die sich statt wie in Unix lieber wie in MS-DOS fühlen wollen und das aktuelle Laufwerk nicht mit cd a: , sondern einfach mit a: einstellen wollen, können sich mit entsprechenden Shellfunktionen helfen. Setzt man sich folgende Zeilen für jedes angemeldete Laufwert ins Profile: a:() { cd a: } A:() { cd a:\ } dann kann man durch Eingabe von a: das aktuelle Laufwerk a: einstellen und durch Eingabe von A: in Mupfel-Manier ins Rootdirectory von a: wechseln. Eine Liste der angemeldeten Laufwerke erhält man bekanntlich mit df -m . Natürlich kann man sich diese Funktionen auch in eine eigene Datei, z.B. msdos.sh, schreiben und diese dann im Profile mit . mshdos.sh aufrufen. Unixfans erstellen außerdem eine Datei namens killmsdos.sh, in der sie mit den Zeilen a:() {} A:() {} usw. (für jedes vorhandene Laufwerk) die MS-DOS-Funktionen wieder löschen. --------------------------------------------------------------------------- C-SHELL-GEFÜHLE Wer sich lieber wie in der C-Shell (/bin/csh) fühlt als wie in der Bourne- Shell, kann sich auch mit Shellfunktionen helfen. In der C-Shell werden Variablen mit dem set-Kommando gesetzt: set() { VAR=$1 VAL=$2 $3 $4 $5 $6 $7 $8 $9 $VAR=$VAL } Environmentvariablen setzt man man mit setenv. setenv() { VAR=$1 VAL=$2 $3 $4 $5 $6 $7 $8 $9 $VAR=$VAL export $VAL } --------------------------------------------------------------------------- GULAM-SHELL UND MASTER In manchen Punkten ist die Gulam-Shell unschlagbar, z.B. was den eingebau- ten Editor und die Regular-Expression-Fähigkeiten (egrep) angeht (im Ernst: auch unter Unix habe ich egrep noch nie benutzt), in anderen Beziehungen hat Okami die Nase vorn (z.B. bei den Möglichkeiten von chmod u.a. Von Pipes, Command Substitution usw. wagt gulam nicht einmal zu träumen.). Man kann die Gulam-Shell von der Okami-Shell aus aufrufen, dabei werden alle exportierten Shellvariablen übergeben und können unter Gulam mit setenv angesehen werden (anders als Okami unterscheidet Gulam zwischen Environment- und Shell-Variablen). Fast dasselbe gilt für dir kommerzielle Master-Shell, von der mir leider nur das Referenznahdbuch zur Verfügung stand. Obwohl Master eine Reihe von Fähig- keiten hat, vor denen Okami sich respektvoll verbeugen muß, z.B. Unix-Filenamen und Regular Expressions bis auf TOS-Ebene, Links und Locks usw., ist Master doch in nicht allen Punkten voraus. Die Shellfunktionen von Okami sind dem alias-System sicherlich in ihrer Flexibilität weit überlegen (programmieren Sie mal while und if in ein alias), und Okami hat eine ganze Reihe von in- ternen Kommandos, die die Programmierung vereinfachen, z.B. basename, test, getscr/putscr usw., die Master vermissen läßt. Ein gewaltiges Plus für Okami ist natürlich der Preis: wer direkt bei mir bestellt, zahlt nicht mehr als zweimal 1,70 für Porto. Außerdem dürfte es schwierig sein, an die Quellen von Master zu gelangen. Ein objektiver Vergleich der Fähigkeiten von Gulam/Master und Okami findet sich in der Datei vergl.doc. (Ja, der Vergleich IST objektiv, auch wenn die beiden dabei etwas schlecht abschneiden. Wer es nicht glaubt, kann sich ja selber mal hinsetzen und so einen Vergleich anfertigen.) ---------------------------------------------------------------------------- DIE VERSIONSNUMMER DER SHELL "Was heißt Manta GTE? - GETUNED EY!!!!!!" (unbekannter Manta-Witz-Erfinder) Damit keine ähnlichen Mutmaßungen über die Bedeutung der Versionsnummer der Okami-Shell aufkommen, hier die genaue Beschreibung, was selbige uns zu sagen hat. Die Versionsnummer, die in der Shell-Variablen $VERSION gespeichert ist und von dem ver-Kommando ausgegeben wird, gibt ziemlich genaue Auskunft über die vorliegende Version der Shell und ist folgendermaßen aufgebaut: z.B. "1.2b+ X" 1 : die Hauptnummer (eine Zahl, gefolgt von einem Punkt) diese Nummer ändert sich nur unter besonderen Umständen, z.B. größeren Umstellungen der Programmstruktur, Bedienung usw. Versionen mit unter- schiedlicher Hauptnummer sind nicht unbedingt kompatibel zueinander. 2 : die Versionsnummer (eine Zahl) kennzeichnet die laufende Nummer der Shell und ändert sich mit den vollständigen (d.h. garantiert vollständig getesteten und dokumen- tierten) Versionen, die von Zeit zu Zeit veröffentlicht werden, wenn mir mal eine Weile nichts neues einfällt (also nicht allzu häufig). Diese Versionen werden über Pd-Versandstellen vertrieben. Alle anderen Angaben treten optional auf: b : die Zwischen-Release-Nummer (ein Kleinbuchstabe) kennzeichnet Releases, die zwischen den o.a. Versionen herauskommen. Wer seine Shell direkt bestellt, bekommt mit großer Wahrscheinlich- keit eine solche Zwischenversion. Sie sind im großen und ganzen fehlerfrei und dokumentiert, obwohl das hier nicht so sicher ist wie bei den Hauptversionen (die keine Zwischen-Release-Nummern haben). + : die Test-Kennung mit dem Pluszeichen werden die Arbeitsversionen gekennzeichnet, die normalerweise nicht veröffentlicht werden. Diese Versionen enthalten möglicherweise noch Fehler. X : die Erweiterungsspezifikation (ein oder mehrere Großbuchstaben) die Großbuchstaben kennzeichnen erweiterte, verkürzte oder konfektio- nierte Versionen. Folgende Erweiterungsspezifikationen können auftre- ten: F die Version enthält eine höhere Anzahl von Shell- funktionen. V die Version enthält eine höhere Anzahl von Shell- variablen. L die Version enthält eine höhere Anzahl von ver- schachtelbaren while-Ebenen. X die Version enthält sonstige Erweiterungen der Kapazität. R die Version ist restriktiv, d.h. sie enthält wesent- lich weniger interne Kommandos als die regulären Versionen. P bei Programmstart wird das Profile immer geladen, außer es wird der Parameter "-" übergeben (die regulären Versionen verhalten sich umgekehrt). K die Version ist auf die Wünsche eines bestimmten Anwenders konfektioniert. Die zeitliche Reihenfolge der Versionen lautet also: 1.3 Hauptrelease 1.3+ Arbeitsversion 1.3a Zwischenrelease 1.3a+ Arbeitsversion 1.3b Zwischenrelease 1.3b+ Arbeitsversion .... 1.4 Hauptrelease 1.4+ Arbeitsversion usw. Eine genauere Analyse der Shell (Anzahl der möglichen Variablen, Shellfunk- tionen und geschachtelten whiles, maximale Zeilenanzahl des sort-Kommandos, Länge des History-Puffers, Größe des UPN-Stacks usw.) kann mit dem Kommando "ver -l" erzeugt werden. ---------------------------------------------------------------------------- DIVERSES Trikolor-Bildschirm: Durch Verwendung des Kommandos scr -b ; cursor +bv 1 auf einem Monochrom-Bildschirm blinkt der Cursor so schnell, daß er wie eine dritte Farbe auf dem Bildschirm wirkt. Dieser Effekt ist jedoch nur bei dunklem Hintergrund (scr -b) deutlich sichtbar. ~~~~~~~~~~~~~~~~~~~ Aufruf vom Desktop: Wenn man sh.ttp vom Desktop aufruft und eine Kommandozeile eingibt, die von der Shell ausgeführt werden soll, so erscheint nach der Ausführung dieser Kommandos wieder das Desktop, ohne daß der Anwender Zeit hat, eventuelle Ausgaben zu lesen. Um das zu verhindern, kann das read-Kommdando benutzt werden. Um z.B. für alle angemeldeten Laufwerke die Platzstatistik (mit dem Kommando df) zu erhalten, klickt man auf sh.ttp und gibt folgende Kommando- zeile ein: df ; read oder df ; echo Taste: ; read (Die Leerzeichen um die Strichpunkte sind nicht unbedingt notwendig). Nach der Ausführung von df wartet die Shell auf eine Eingabe (die durch Druck auf RETURN beendet sein muß). Im zweiten Beispiel wird außerdem noch der Text "Taste:" ausgegeben. ~~~~~~~~~~~~~~~~~~~~~~~~~~ Zweideutige Kommandonamen: Wenn ein Programm denselben Namen wie ein internes Shellkommando hat, dann kann dieses Programm nicht einfach mit Namen aufgerufen werden. Hat man z.B. ein Script namens test.sh, dann wird durch Eingabe von "test" nicht das Script, sondern das interne Kommando "test" aufgerufen. Um das zu ver- hindern, gibt man den Kommandonamen in Großbuchstaben ein, also "TEST" oder "Test", dann wird das externe Kommando aufgerufen. Das liegt daran, daß Groß-Kleinschreibung bei internen Kommandos von Bedeutung ist, bei Datei- namen und damit bei externen Kommandos aber nicht. ~~~~~~~~~~~~~~~~ Compiler-Aufruf: Folgende Zeilen habe ich im Aufrufshellscript für den Compiler: d=`date` echo #define _CMP_DAT "$d" >$INC/cmpdat.h d= Dies erzeugt bei jedem Compileraufruf eine Headerdatei namens cmpdat.h (die Environmentvariable INC speichert den Pfad der Headerdateien), in der ein Makro namens _CMP_DAT definiert wird, das das aktuelle Datum beinhaltet, z.B. #define _CMP_DAT "03.09.1990 19:33:42" Diese Datei in die C-Quellen eingebunden, und man hat in jedem Programm das individuelle Datum der Erstellung. Das Ergebnis kann man sich in der Okami-Shell mit "ver -c" ansehen. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Ändern von Dateinamen-Extendern: Die Kommandos basename, dirname und extname kann man benutzen, um den Extender einer Datei zu ändern, z.B. um zu einer C-Quelldatei den Namen der zugehörigen Objektdatei zu ermitteln. Man kann dieses Kommando zusammen mit dirname benutzen, um z.B. zu dem Namen einer C-Quelldatei den Namen der zugehörigen Objektdatei zu ermitteln. echo Bitte einen C-Quelldateinamen eingeben: read FILE EXT=`extname $FILE` if [ $EXT != .c ] then echo Das ist keine C-Quelldatei! else DIR=`dirname $FILE` FILE=`basename $FILE .c` echo Die Objektdatei ist $DIR/$FILE.o fi Ergibt: Bitte einen C-Quelldateinamen eingeben: e:/okami/cmds4.c Die Objektdatei ist e:/okami/cmds4.o