Öko-Touch: Hausgemachte Batch-Dateien für den Atari-Desktop

Die von vielen »alternativen« Desktops her bekannten Batch-Dateien lassen sich in Form von kleinen Programmen meist auch auf der Atari-Oberfläche einsetzen und sparen auch ohne großen Overhead eine Menge Arbeit.

Trotz deutlicher Aufwertung des Atari-Desktops durch die Version 2.05 bzw. 3.0 bei den TT-Modellen, übertreffen die sogenannten »alternativen« Desktops wie Gemini das Original sowohl an Funktionalität wie auch an Bedienungskomfort. Besonderes Manko ist hier der fehlende Kommandozeileninterpreter. Ohne gleich neue politische Thesen aufstellen zu wollen, besteht wohl kein Zweifel daran, daß man die »Alternativen« hauptsächlich wegen ihres hohen Resourcenverbrauches meidet. Hierbei ist nicht nur an die Resource Speicher gedacht. Fast in gleichem Maße betrifft dies auch die Rechenzeit: »Willkommen bei GEMINI! ...« - Wann? Im nächsten Jahr? Bei kommerziellen oder Shareware-Desktops benötigt man dann noch den Rohstoff schlechthin, nämlich das liebe gute Geld.

Viele Funktionen lassen sich jedoch weitaus ökologischer herbeizaubern. Denn oft reicht schon ein kleines Programm, das die gewünschte Funktion nachbildet. Solche Programme genügen außerdem, weil selbst geschrieben, viel eher den eigenen Ansprüchen. Vorteilhaft, aber nicht unbedingt erforderlich ist die Möglichkeit, einzelne Programme auf den Desktop-Hintergrund ziehen zu können, wie es die TOS-Versionen ab 2.05 gestatten. Hierdurch entfällt das lästige Suchen der Programme in den Fenstern. Beim Aufruf der Programme ist meistens noch die Kommandozeile von Bedeutung. Schiebt man ein Datei-Icon auf eines dieser Programme, wird es mit dem Dateinamen als Parameter aufgerufen. Durch das optionale Voranstellen einer Kommandozeile über den Menüpunkt »Extras/Anwendung anmelden ...« läßt sich der größte Teil der Anwendungsbereiche zur Genüge abdecken. Gilt es aber, mehrere Programme mit fest vorgeschriebenen Kommandozeilen nacheinander zu einer Anwendung zusammenzufassen, sind Batch-Dateien unerläßlich. Zum Beispiel könnte eine Applikation ein temporäres Verzeichnis benötigen, das vor dem Aufruf anzulegen und hinterher wieder zu löschen ist. Sicherlich läßt sich diese Aufgabe auch »zu Fuß« bewältigen, doch ließe sich das Gleiche in einer dreizeiligen Batch-Datei unterbringen.

Wenn sich darüberhinaus die Batch-Dateien auf den Desktop ziehen lassen, wie zum Beispiel unter GEMINI die »*.MUP«-Dateien, und man diese wie ganz normale Programme aufruft, genügt schon ein einziger Doppelklick der Maus für eine so komplexe Aufgabe. Dort wird dann nämlich der integrierte Kommandozeileninterpreter aktiv, der Zeile für Zeile der Batch-Datei abarbeitet. Außerdem startet der Interpreter auch dann, wenn man ein anderes Datei-Icon auf die Batch-Datei schiebt. In diesem Falle bestimmt die Batch-Datei, wie mit dem übergebenen Argument umzugehen ist.

Zum Interpreter gibt es natürlich nun die compilierte Alternative. Die Vor- und Nachteile von Interpretern gegenüber Compilern wollen wir hier nicht erörtern, zumal wir ausgehend vom Atari-Desktop ohnehin nicht die Wahl haben. Dennoch verlangt unsere Alternative immer noch einen Hochsprachen-Compiler (hier Pure-C). Mit einem solchen läßt sich der Kommandozeileninterpreter mit Sicherheit immer ersetzen; die Frage ist nur, mit welchem Aufwand. Für das erste Batch-Compilat mag sich der Programmieraufwand noch nicht rechnen, doch mit der auf der TOS-Diskette beigelegten Funktionssammlung sind die Compiler-Quelltexte nahezu genausogut zu lesen wie die Batch-Dateien und flexibler gegenüber einem Kommandozeileninterpreter ist ein Compiler allemal. Die aufwendigste Arbeit, die ein Batch-Programm zu bewerkstelligen hat, ist das Hantieren mit den übergebenen Argumenten. Anders als beim Programmaufruf via Kommandozeileninterpreter liegen die Argumente für den C-Programmierer bereits aufgesplittet vor (»argc«, »argv«). Will man diese Argumente an ein Programm weiterleiten, sind diese erst wieder mit Leerzeichen (» «) zu einem einzigen Parameter zu verbinden.

Um eine möglichst hohe funktionale Auslastung zu erreichen, empfiehlt es sich oft, als Argument nicht nur Dateinamen, sondern gleich ganze Pfade zuzulassen.

In Abhängigkeit des Argumenttyps (Pfad oder Dateiname) kann so ein Batch-Programm gleich für zwei Aufgaben dienen.

Ein Beispiel, das auch für einen größeren Anwenderkreis gute Dienste leistet, und im einen oder anderen Fall eine ganze Programmgattungen ablösen kann, nämlich die der Packer-Oberflächen, ist schnell gefunden. Exemplarisch für alle bekannten Kommandozeilenpacker soll hier anhand von »LHarc« ein kleines Batch-Programm aufzeigen, wie man durch Ziehen eines Ordner-Icons auf das Batch-Programm ohne weitere lästige Tipparbeit diesen Ordner mit allen Unterverzeichnissen »einpackt«. Da sich der Aufbau der Kommandozeile aller Packer ähnelt, sollte eine entsprechende Anpassung an den sonst favorisierten Packer keine unüberwindbaren Probleme bereiten. Die Aufgabe des Batch-Programms besteht nun darin, aus einem vom Desktop übergebenen Verzeichnisnamen eine Kommandozeile für den Packer zusammmenzubauen, so daß dieser alle Dateien innerhalb des Verzeichnisses zu einem Archiv zusammenfaßt und das Archiv im aktuellen Fenster unter dem Namen des Ordners (mit der passenden Archiverweiterung, z.B.: ».LZH«) ablegt.

Zwei Wege fuhren zur Pfadangabe

Um den Pfad des aktuellen Desktop-Fensters sowie den Pfad des aufgerufenen Batch-Programmes zu ermitteln, bieten sich zwei Wege an. Beide haben ihre Vor- und Nachteile beziehungsweise vertragen sich nicht mit jeder TOS-Version. Der einfachere Weg führt über den Menüpunkt »Extras/Anwendung anmelden ...« (ab TOS 2.05) im Desktop. Optional erhält das Batch-Programm als Standardpfad den des aktuellen Fenster. Dann bleibt noch das Problem, das eigentliche Packprogramm zu finden.

Die Auswertung der Environment-Variable »PATH« oder die Suche via »shel_find()« führen erst ab MultiTOS zum gewünschten Ziel, da erst hier »PATH« um beliebige Einträge erweitert werden darf. Also nimmt man entweder den Pfad des Packers direkt in das Batch-Programm auf, was eine Neucompilierung nach jedem Verschieben des Packers verlangt, oder aber man verlangt nur, daß Batch-Programm und Packer im gleichen Verzeichnis stehen müssen. Da der Desktop seine Programme immer mit »shel_write()« startet (also nicht mit »Pexec()«), gelangt man mit »shel_read()« an den Programmnamen inklusive Pfadangabe des eigenen Programmes, in unserem Falle also an den des Batch-Programmes. Jetzt trennt man den Programmnamen vom Pfad ab und hängt den des Packers an.

Die zweite Lösung scheint auf den ersten Blick eleganter, hat aber auch einen Haken. Wir verlangen, daß sich Batch-Programm und Packer im gleichen Ordner befinden müssen. Den Desktop stellen wir so ein, daß das Batch-Programm immer mit dem Pfad des Batch-Programms zu starten ist. Auf diese Weise muß das Batch-Programm den Packer nur im aktuellen Verzeichnis suchen.

Bleibt noch die Aufgabe, den Pfad des aktuellen Desktop-Fensters zu ermitteln, denn dort soll der Packer ja das Archiv anlegen. Hierzu dient uns der Desktop-Shell-Buffer, den wir uns mittels »shel_get()« besorgen. Den Aufbau des Shell-Puffers hat Atari zwar nie dokumentiert, allerdings entspricht er bei allen bekannten TOS-Versionen exakt dem Aufbau der »DESKTOP.INF«-Datei. Und wer schon einmal einen Blick in diese Datei geworfen hat, dem ist vielleicht aufgefallen, daß hierin auch jedem Desktop-Fenster eine eigene Zeile gewidmet ist. Diese Zeilen beginnen immer mit »?«, wobei die letzte dieser Zeilen dem aktuellen Fenster entspricht. Da der Desktop nach jedem Fensterwechsel den Shell-Buffer anpaßt, suchen wir zur Ermittlung des aktuellen Pfades nach der letzten »?«-Zeile. Am Ende dieser Zeile steht dann der Pfadname des aktuellen Fensters. Schwachpunkt der ganzen Angelegenheit: Unter MultiTOS, das ja nicht zwingend einen Desktop fordert, mag der beschriebene Weg im Zweifelsfall versagen, bei allen bekannten TOS-Versionen bietet er aber den größeren Spielraum für die Batch-Programme.

Mit dem kleinen Packer-Batch-Programm inklusive C-Quelltexten auf der TOS-Diskette und weiteren hilfreichen Funktionen dürfte die Hürde, erst zu einem Compiler greifen zu müssen, der die Befehlssequenzen zu einem Programm zusammenfaßt, auch für weniger Sportliche auf ein überspringbares Niveau gesenkt sein. (ah)