Wget - Surfen einmal anders

Im dritten und letzten Teil beschätigen wir uns noch mit ein paar Optionen, die das rekursive Saugen noch angenehmer machen können. Dabei besprechen wir u.a Timestamping, das Konvertieren von Verweisen und ein paar weitere Optionen, die oft nützlich sind. Weiters wird die Funktion der Konfigurationsdatei ".wgetrc" beschrieben. Anschließend gibt es noch ein paar Anmerkungen, wann Wget nicht so richtig hinhaut. Und zum Schluß integrieren wir das gute Stück mit ein bißchen ARexx in unseren Browser.

Timestamping

Pfui, ein englischer Begriff in der Überschrift, und das auch noch am Anfang des Artikels! Gnagnagna, keiner scheint zu wissen, wie man das sinnvoll übersetzen kann, und bevor hier ein kaputtes Computerdeutsch regiert, bleiben wir doch lieber beim englischen Begriff.

Die Idee des Timestamping ist, daß Wget sich merkt, wann eine Datei zuletzt geändert wurde. Das heißt, beim Saugen erhält die lokale Kopie nicht Datum und Zeit des Abspeicherns am eigenen Rechner, sondern jenes der letzten Änderung am Original vom Server.

Das ist eine feine Sache, denn dadurch ist es später ein Leichtes, herauszufinden, welche Dateien am selben Server neu sind seit dem letzten Saugen.

In der Praxis sieht das so aus: Wir erinnern uns, daß wir vor einiger Zeit die Homepage der beliebten Band "Half Man Half Biscuit" kopiert haben. Dazu haben wir prinzipiell folgenden Aufruf verwendet:

wget --recursive --no-parent --exclude-directories=/~hmhb/fallnet http://www.btinternet.com/~hmhb/hmhb.htm

Angenommen, die Truppe hat ein neues Album herausgebracht, und die Homepage wurde entsprechend erweitert im Sinne von Verständnishinweisen zu neuen Texten und allerlei Querverweisen von/zu bereits vorhandenem Material. Viele Dateien wären aber nach wie vor unverändert, sollen also nicht noch einmal geholt werden.

Die bereits bekannte Option --no-clobber ist hier nicht hilfreich, da --no-clobber nie eine Datei holt, wenn sie bereits als lokale Kopie existiert. Selbst wenn das Original am Server bereits neuer ist.

Stattdessen verwenden wir diesmal die Option --timestamping. Auf unser Beispiel angewendet heißt das:

wget --timestamping --recursive --no-parent --exclude-directories=/~hmhb/fallnet http://www.btinternet.com/~hmhb/hmhb.htm

Im Falle, daß eine Datei auf www.btinternet.com geändert oder neu angelegt wurde, wird diese erneut kopiert. Unveränderte Dateien hingegen fertigt Wget mit einer Meldung wie folgt ab:

Local file `www.btinternet.com/%7Ehmhb/hmhb.htm' is more recent, not retrieving.

Timestamping stellt aber dennoch einige Anforderungen an das Netz, da für jede Datei eine Verbindung aufgebaut werden muß, um das Datum des Originals am Server zu vergleichen. Im Unterschied dazu stellt --no-clobber nur dann eine Verbindung mit dem Server her, wenn eine Datei überhaupt nicht existiert.

Das einzige, was man sich mit --timestamping spart, ist das tatsächliche Saugen der eigentlichen Daten. Sind dies viele kleine Dateien, so dauern die Überprüfungen dieser Option immer noch eine Weile, da zwischen Server und Wget einiges an Information ausgetauscht wird, auch wenn der Anwender davon nicht viel zu sehen bekommt.

Timestamping macht also vor allem dann Sinn, wenn es alle paar Wochen einmal verwendet wird, und man zuvor mit einem "klassischem" Browser überprüft hat, ob sich überhaupt etwas geändert hat. Zu diesem Zwecke haben viele Websites eine "What's new" Seite, die schnell überflogen ist.

Verweise konvertieren

Ein Problem beim Kopieren von ganzen Verzeichnissen mittels Wget ist manchmal, daß der Webdesigner nicht überall dort, wo es möglich ist, lokale Verweise verwendet.

Ein lokaler Verweis auf eine andere Datei ist, wenn in der URI kein Server angegeben ist, sondern nur ein anderer Dateiname. Ein Beispiel für einen lokalen Link aus den Seiten des AmigaScenes wäre, daß alle Seiten auf die Hauptseite mittels welcome.html verweisen können. In HTML würde das so aussehen:

<a href="welcome.html">Zur Hauptseite</a>

Den vorerst scheinbar gleichen Effekt kann man erzielen, wenn man die ganze Wurst mit Servername & Co. angibt, also:

<a href="http://www.amigascene.com/welcome.html">Zur Hauptseite</a>

Der große Unterschied ist aber sofort erkennbar, wenn man einen solchen "globalen" Verweise in einer kopierten Datei auf der eigenen Platte hat: Der zuvor gezeigte lokale Link erwartet welcome.html nun auch auf der Festplatte, mit der globalen Variante will sie aber nach wie vor aus dem Netz geholt werden.

Für uns ist es natürlich am besten, wenn alle Verweise lokaler Natur sind, weil wir das Netz meiden wollen wie die Pest. Glücklicherweise gibt es in Wget die CLI-Option --convert-links. Diese macht eben nichts anderes, als alle HTML-Dateien nach "bösen" globalen Verweisen zu durchsuchen, und dann automatisch in die für uns weitaus praktischeren lokalen Links zu konvertieren.

Wissenswert zu dem Vorgang ist noch, daß er erst nach dem Kopieren durchgeführt wird. Wget konvertiert einen Link nämlich nur, wenn die entsprechende Datei auch lokal vorhanden ist. Und das kann natürlich erst mit Sicherheit gesagt werden, wenn keine neuen Dateien mehr zu erwarten sind.

In der Ausgabe von Wget verdeutlicht sich --convert-links üblicherweise am Ende. Da rattert dann eine Liste von Meldungen wie

Converting www.amigascene/0x004C.html... done.

vor den Augen des zufrieden grinsenden Anwenders vorbei.

Erwähnenswert dazu vielleicht auch noch, daß die Links im AmigaScene ohnehin schon lokaler Natur sind, und daß es sowieso eine Download Seite gibt, wo man sich die Ausgaben zum Offline-Lesen besorgen kann.

Weitere Optionen

Die Unzahl der Optionen von Wget ist so groß, daß dieser Workshop sie natürlich nicht alle besprechen kann. Allgemein kann man sagen: Wann immer einem etwas nicht paßt, dann gibt es einen Parameter, um das zu ändern. Es sei auf die Originaldokumentation und deren Index hingewiesen.

Hier werden nur noch ein paar zusätzliche Features besprochen, die sich oft als praktisch erweisen.

Zuerst einmal gibt es da --directory-prefix. Damit kann man ein Zielverzeichnis angeben, in dem alle Dateien landen sollen.

Da Wget die ixemul.library benutzt, müssen Pfade den Unix-Konventionen nach angegeben werden. Konkret bedeutet dies: das übergeordnete Verzeichnis heißt nicht mehr "/", sondern "../". Laufwerke und Assigns haben statt einem Doppelpunkt (:) am Ende einen Schrägstrich (/) am Anfang. Ein paar Beispiele:

Amiga	ixemul.library
Work:	/Work/
/sepp/resi/	../sepp/resi/
Sys:libs/	/Sys/libs/
s:user-startup	/s/user-startup

(Die Profis könnten jetzt aufmucken, daß man die ixemul.library durch ein bißchen gutes Zureden davon überzeugen kann, auch Dinge wie --directory-prefix=ram: zu akzeptieren. Das ist zwar richtig, aber problematisch, weil viele Unix-Programme dem Doppelpunkt andere Bedeutungen zuordnen, und dieser Ansatz dann am Amiga nicht mehr funktioniert. Aber das würde den Nicht-Freak nur verwirren, und deshalb entfällt hier eine erschöpfende Diskussion des Problems.)

Die Option -x bewirkt, daß sogar dann von Wget die Verzeichnisstruktur des Servers erzeugt wird, wenn nur eine einzelne Datei geholt wird. Einmal mehr gibt es keine dokumentierte Langform dazu. Es sei auch wiederholt darauf hingewiesen, daß Wget bei der Groß/Kleinschreibung unterscheidet, und -x und -X zwei verschiedene Sachen sind. Letzteres ist die Kurzform des aus Teil zwei bekannten --exclude-directories.

Ein paar Beispiele:

wget http://www.cucug.org/aminew.html

kopiert die Datei aminew.html ins aktuelle Verzeichnis, hingegen nach einem

wget -x http://www.cucug.org/aminew.html

liegt sie in www.cucug.org/aminew.html. Und ein

wget -x --directory-prefix=/ram/ http://www.cucug.org/aminew.html

bewirkt, daß sie in ram:www.cucug.org/aminew.html landet. Man beachte, daß als Zielverzeichnis /ram/ angegeben wurde, um ram: zu erhalten.

Die Konfigurationsdatei

Im ersten Teil wurde kurz Datei namens .wgetrc erwähnt. Außer, daß sie an einen geeigneten Platz kopiert wurde, ist damit noch nicht viel gemacht worden. Also wozu ist das Ding eigentlich gut?

Banal gesagt handelt es sich dabei um eine Datei, die von Wget automatisch gelesen wird, sobald es gestartet wurde. Das .wgetrc läßt sich mit einem beliebigen Texteditor (wie z.B. c:Ed oder sys:Tools/memacs) bearbeiten. Vereinfacht gesagt kann man in jede Zeile einen Ersatz für eine der zahlreichen CLI-Optionen eintragen, die dann automatisch immer gesetzt ist.

Bevor auf die Details eingegangen wird, mag der verwunderte Leser fragen, wie ein Mensch auf so einen dümmlichen Namen wie .wgetrc kommen mag. Die Antwort lautet, wie nicht anders zu erwarten, einmal mehr: Unix-Tradition.

Eine der herausragenden Peinlichkeiten von Unix ist, daß es so gut wie keine vorgeschriebene Verzeichnisstruktur gibt. In der Folge weiß niemand, wohin mit Konfigurationsdateien, und deshalb werden die grundsätzlich ins Hauptverzeichnis des jeweiligen Anwenders geramscht. Nachdem man ein paar Applikationen installiert hat, liegen dort bald Dutzende solcher Dateien herum.

Wohlgemerkt, das Chaos herrscht dann in dem Verzeichnis, wo man sich nach dem Einloggen üblicherweise befindet. Natürlich ist bei uns Amiganern das env: und envarc: auch ein irrsinniger Sauhaufen, nur geht man dort nie ohne guten Grund hin.

Das ist nicht so angenehm, hat sich sogar der Unix-Mann gedacht, und prompt eine Lösung zu dem Problem erfunden: Wenn der Name einer Datei mit einem Punkt (.) beginnt, dann wird sie beim Auflisten eines Verzeichnisses (normalerweise) versteckt. Dank dieser wahrhaftig großartigen Idee konnte es vermieden werden, sich eine vernünftige Lösung des eigentlich Problems einfallen zu lassen.

Und weshalb "rc" am Ende von .wgetrc? Das ist die Abkürzung für "remote control", was etwa soviel heißt wie "Fernsteuerung". Viel steuern kann man damit aber nicht mehr, sobald das Programm einmal gestartet ist. Der Hauptzweck der Abkürzung besteht eigentlich nur darin, den Namen vollkommen unaussprechlich zu machen, damit er dann auch schwieriger zu merken ist. Unix-Tradition eben.

Sehen wir uns das Ding, das wir im ersten Teil des Workshops installiert haben, also einmal an. Dort finden sich z.B. folgende Zeilen:

# # Anzahl der erneuten Versuche, falls die Verbindung zusammenbricht. # tries = 20

Es sollte nicht schwer sein, dies nachzuvollziehen: Eine Zeile, die mit einem Kasterl (#) beginnt, leitet ein Kommentar ein. Der Rest der Zeile wird dann also ignoriert.

Die Zeile mit tries = 20 hingegen hat die gleiche Wirkung, als ob man beim Aufruf von Wget ein --tries=20 angegeben hätte. Folgendes scheint aufzufallen:

In .wgetrc braucht man das dämliche Minus-Minus (--) nicht anzugegeben.

Man kann die selben Namen verwenden wie im CLI.

Huch, das klingt ja fast praktisch, wie konnte das passieren? Hat sich der Programmierer am Ende etwas dabei gedacht, als er die Syntax für das .wgetrc erfand?

Natürlich nicht. Das war gerade ein Zufallstreffer. Betrachten wir folgenden Eintrag:

# # Maximale Anzahl von Rekursionen für '--recursive' # reclevel = 5

Mit einiger Phantasie kommt man darauf, daß es sich hier um die Entsprechung zur CLI-Option --level handelt, die nur in Kraft tritt, wenn auch --recursive angegeben wurde. Warum dann hier nicht level = 5 steht weiß nur der Heilige Karl, der Schutzpatron der Unix-Männer und Bierzeltklatscher.

Uneingeschränkt wahr ist aber, daß hier das dämliche Minus-Minus wirklich nicht mehr notwendig ist.

Der Wert 5 ist durchaus sinnvoll, und fungiert als "Notbremse". Eine höhere Verschachtelungstiefe ist zwar selten gefragt, wie wir im zweiten Teil gesehen haben, manchmal aber doch. In so einem Fall kann man nach wie vor im CLI z.B. ein --level=9 angeben. Der Wert aus der Konfigurationsdatei wird damit "überschrieben".

Generell kann man also sagen: Es gibt zu den meisten CLI-Optionen ein Entsprechung für .wgetrc, die meistens den gleichen, manchmal einen ähnlichen Namen hat. Wie diese jetzt konkret lauten, kann man der Dokumentation entnehmen.

Wir wollen hier noch ein paar Optionen besprechen, die besser in der Konfigurationsdatei aufgehoben sind als im CLI. Da ist wäre etwa der Eintrag

quota = 5M

Diese Zeile beschreibt das Maximum an Daten, das Wget während eines Aufrufs an Land zieht. 5M steht klarerweise für 5 Megabytes. Man könnte genausogut sagen quota = 5120K oder quota = 5242880.

Wichtig dabei ist noch, daß Wget erst nach dem vollständigen Kopieren einer Datei überprüft, ob diese Grenze überschritten wurde. Wenn wir mit diesem Wert in .wgetrc nocheinmal versuchen, das 8 MB große Archiv für NetBSD aus dem ersten Teil zu saugen, dann klappt das also noch immer, weil es sich nur um eine einzelne Datei handelt, und die Quota-Bremse erst nachher greift.

Den Meisten, die sich einmal mit der Konfiguration eines Browsers auseinandergesetzt haben, werden auch folgende Zeilen schnell klar sein:

use_proxy = on

Wer seinen Proxy nicht über eine Umgebungsvariable bereits gesetzt hat, muß ihn noch explizit angeben, damit er wirklich benutzt wird:

http_proxy = http://wwwcache.tu-graz.ac.at:75/

Ein Proxy ist eine Art WWW-Cache auf einem anderen Rechner. Prinzipiell ist das eine gute Sache. Leider ist dieses Proxy-Ding in technischer Hinsicht einmal mehr eine elendige Pfuscherei. Weiters sind die Leute, die den fernen Proxyrechner warten, mit der Konfiguration oft geistig überfordert, sodaß es für viele nur Scherereien bringt. Mancheiner zieht dann wohl eher folgenden Eintrag vor:

use_proxy = off

Bandbreitenphilosphen müssen nach so einer Behauptung natürlich aufjaulen. Also noch einmal: Solltet ihr einen Proxy haben, und tut er aus unerfindlichen Gründe zufällig funktionieren, tut's ihn auch verwenden, liebe Leute!

Zur weiteren Besänftigung der zuvor Genannten könnte folgender Eintrag dienen:

wait = 1

Dies bewirkt, daß Wget nach dem Saugen einer Datei ca. eine Sekunde lang wartet, bevor die nächste angefordert wird. Denn vor allem dann, wenn Wget über eine halbwegs flotte Ethernet-Leitung nuckelt, kann die Saugerei für den Server am anderen Ende eine ziemliche Belastung sein, da er andauernd Vollgas nachschaufelt.

Läßt man Wget aber zwischendurch immer wieder ein bißchen warten, so kann der Server dazwischen kurz Luftholen, und in Ruhe Anfragen von anderen Browsern bearbeiten.

Weiters ist es damit auch leichter zu beobachten, ob Wget noch immer sinnvolle Daten holt, oder ob es gerade begonnen hat, seine Aufmerksamkeit einer Datei mit der verdächtigen Endung .wav oder dergleichen zu widmen.

Auf der anderen Seite ist es für die Modem-Wabbler daheim besser, wenn sie stattdessen ein

wait = 0

machen oder die Zeile ganz rauslöschen, was aufs gleiche rauskommt. Denn Verbindungen mit Übertragunsraten unter 10 KB/s schaukelt jeder aufrechte Server mit dem kleinen Finger, ohne dabei außer Atem zu kommen. Und selbst Volkschüler im zweiten Jahr sollten die Ausgabe noch angenehm mitlesen können. Die Wartesekunden aber würden auf die Dauer einiges an Geld kosten.

Jene, die sich ein bißchen mit HTTP, dem dümmlichen Leib- und Magenprotokoll des WWW beschäftigt haben, wissen, daß man beim Anfordern einer Datei allerlei Dinge im "Kopf" der Anweisung mitschicken kann. In .wgetrc gibt es dafür header. Details über sinnvolle Werte und deren Effekt weiß die Spezifikation von HTTP. Hier werden ein paar konkrete Dinge beschrieben. Zum Beispiel kann man die bevorzugte Sprache angeben:

header=Accept-Language: en

oder von wo man kommt:

header=From: Mein Name <ich@irgend.wo>

Natürlich ist hier der eigene Name einzutragen. Es bringt übrigens wenig, hier einen lustigen Phantasiewert zu verwenden und zu glauben, daß man dann anonym ist.

Man kann header auch öfters in .wgetrc verwenden, um mehrere Sachen zu kombinieren.

Das unglücklicherweise oft notwendige "Spoofing" geht damit aber leider nicht. Ein

header=User-agent: Mozilla/5.0 (AmigaOS/mc680x0)

bringt nicht den gewünschten Erfolg, sollte sich ein schwachsinniger Web-Autor einbilden, daß man unbedingt einen bestimmten Browser braucht, um seine Seiten betrachten zu können. Offiziell kann man dagegen nichts machen, inoffiziell gibt es die in der Dokumentation unerwähnte CLI-Option --user-agent (kurz: -U):

wget --user-agent=Mozilla/5.0 ...

Damit täuscht Wget vor, Netscape zu sein.

Grenzen von Wget

Nachdem dem wir jetzt wissen, was wir mit Wget alles machen können, fehlt noch der Teil, der sagt, was man damit nicht machen kann.

Zuerst einmal kann Wget keine CGI-Scripts ausführen. Ohne groß darauf einzugehen, was CGI ist, hier die praktischen Auswirkungen von dieser Tatsache: Die ohnehin sinnlosen Webcounter fehlen also in der lokalen Kopie. Und Formulare funktionieren auf der Festplatte in der Regel auch nicht mehr.

Eine weitere Grenze liegt in der geistigen Beschränkheit von Webdesignern. Manche halten es für notwenig, sich über die HTML-gegebenen Verweismechanismen hinwegzusetzen, und die Navigation über abstruse Javascript-Platitüden machen zu müssen. Wget ignoriert derlei Sachen natürlich, und verfolgt auch keine solcherart erzeugten Pseudolinks.

Eine Erwähnung wert sind auch Seiten mit Frames. Weil das Framekonzept von intellektuell ziemlich minderbemittelten Menschen stammt, besteht eine Frameseite aus mehreren Dateien. Deshalb besorgt ein normaler Aufruf von Wget nur die Seite, die sagt, wo die eigentlichen Frameinhalte liegen. Ansehen kann man sich damit natürlich nicht viel. Dieses Problem läßt sich aber einfach lösen, indem man die Optionen --recursive --level=1 mit angibt (und eventuell --reject & Co.).

Wget vom Browser aus starten

Jetzt wo wir wissen, wie Wget funktioniert, fragt sich der eine oder andere wahrscheinlich, ob er sich die 986432 CLI-Optionen wirklich merken soll. Die Antwort lautet schlicht und ergreifend: Nein. Sowas tun nur Unix-Männer.

Bereits im zweiten Teil haben wir uns zuerst mit ein paar CLI-Aliasen und zwei einfachen ARexx-Scripts beholfen. Das war zwar schon recht praktisch, dennoch mußte dazu noch immer der CLI offen bleiben. Eigentlich wäre es angenehm, wenn man beim Betrachten einer interessanten Seite einmal mit der Maus klickt, und das gute Stück ist auf der Platte.

Mit ARexx und einem "vernünftigen" Browser ist das auch tatsächlich einfach zu bewerkstelligen. Vernünftig in diesem Zusammenhang heißt AWeb oder IBrowse, aber nicht Voyager. Letzterer hat zumindest in der derzeit aktuellen Version 2.95 einen zu beschränkten Befehlssatz in seinem ARexx-Port.

Das ARexx-Script, das eben dies bewerkstelligt heißt banal wget.rexx. Zu finden sind sie entweder am Ende des Artikels oder am Aminet unter comm/www/WgetRexx.lha.

Im weiteren Verlauf des Workshops wird die Einbindung in IBrowse beschrieben, für AWeb verläuft der ganze Vorgang aber analog, außer daß ein paar Dinge im Preferencesfenster etwas andere Namen haben.

Der Browser muß laufen, und die Seite, die wir haben wollen, muß gerade angezeigt werden. Weiters brauchen wir einen Assign namens Web:, wo unsere lokale Kopie der interessanten Teile des WWW liegen wird. Wem nichts besseres einfällt, der kann im CLI ein

makedir Work:Web assign Web: Work:web

machen, und den Assign auch in seiner s:user-startup aufnehmen. Das Script sorgt dafür, daß alles, was es besorgt, automatisch dort landet.

Das Script selbst kopieren wir am besten nach rexx:, da es nicht nur einen Browser unterstützt, sondern einfach mit dem kommuniziert, der gerade rennt. Das hat auch den Vorteil, daß der rx Befehl automatisch dort danach sucht, und wir keine langen Pfade angeben müssen.

Weiters werden zum die beiden Libraries rexxreqtools.library und rexxdossupport.library benötigt. Wer die noch nicht hat kann sie sich aus dem Aminet besorgen, Details über die Archivnamen finden sich am Ende des Workshops.

Für die ersten Gehversuche werden wir das Script vorerst einmal vom CLI aus starten, und wenn klar ist, wie die Sache abläuft, den Aufruf im ARexx-Macro Menü des Browsers ablegen.

Also flux den Browser gestartet, und ihn eine interessante Seite anzeigen lassen. Aus Gründen der Konsistenz könnte das einmal die beliebten HMHB sein, also http://www.btinternet.com/~hmhb/hmhb.htm. Jetzt im CLI folgendes eingeben:

rx wget.rexx

Der Anfang der Ausgabe sollte wie folgt aussehen:

Downloading "http://www.btinternet.com/~hmhb/hmhb.htm" to file://localhost/Web:www.btinternet.com/%7Ehmhb/hmhb.htm" wget -x --directory-prefix=/Web/ http://www.btinternet.com/~hmhb/hmhb.htm

Die ersten beiden Zeilen geben an, was wohin kopiert wird. Das file://localhost/Web:www.btinternet.com/%7Ehmhb/hmhb.htm ist dabei die URI der lokalen Kopie, die wir danach im Browser sehen werden. Das file://localhost/ besagt nichts anderes, als daß es sich dabei um eine Daten auf unserem eigenen Rechner handelt. Demzufolge ist auch keinen Netzwerkzugriff erforderlich, um sie anzuzeigen..

Die zweite Zeile gibt den tatsächlich verwendeten Aufruf für Wget an. Wie wir sehen, fügt das Skript immer die Optionen --directory-prefix und -x dazu. Das --directory-prefix=/Web/ dafür, daß alles in Web: landet, und wegen dem -x wird immer für jeden Server ein eigenes Verzeichnis erzeugt, auch wenn nur eine einzelne Datei gesaugt wird.

Die URI http://www.btinternet.com/~hmhb/hmhb.htm weiß das Script, weil es den Browser über ARexx "gefragt" hat.

Es sollte im weiteren Verlauf die normale Ausgabe von Wget folgen, und am Ende folgender Nachsatz stehen:

Successfully downloaded data to local web. Viewing page in Browser.

Wenn alles geklappt hat, flackert der Browser kurz auf, und zeigt wirklich die Datei file://localhost/Web:www.btinternet.com/%7Ehmhb/hmhb.htm an. In dem Fall handelt es sich um die Kopie der HMHB-Seite ohne Bilder.

Man kann nun an das Script weitere Optionen übergeben, die direkt an Wget weitergereicht werden. So läßt sich damit auch die ganze Site kopieren. Weil wir aus dem zweiten Teil bereits wissen, wie man HMHB ohne den Schrott in /fallnet saugt, könnte man genausogut folgendes machen:

rx wget.rexx --recursive --no-parent --exclude-directories=/~hmhb/fallnet

Sollte der Browser übrigens immer noch die lokale Kopie mit der URI file://localhost/Web:... anzeigen, so ist das Script schlau genug, davon ausgehend die ursprüngliche Adresse mit http://... berechnen.

Die ARexx-Scripts einbinden

Das Einzige, was noch fehlt, ist, die Scripts direkt vom Browser aus aufzurufen. In IBrowse gibt es das praktische Menü "Rexx", das man von Preferences/General/Rexx aus konfigurieren kann. Das Feld Name gibt dabei den Namen des Menüpunkts an, unter dem das Macro danach im Rexx-Menü zu sehen sein wird, das Feld Macro den Aufruf selbst. Für den Anfang wäre folgende Konfiguration denkbar:

Name	Macro
Wget single resource	wget.rexx
Wget page with images	wget.rexx --recursive --convert-links --level=1 --accept=png,jpg,jpeg,gif
Wget site	wget.rexx --recursive --convert-links --no-parent --reject=mpg,mpeg,wav,au,aiff,aif,tgz,Z,gz,zip,lha,lzx,ps

Das "Wget single resource" entspricht unserem ersten Beispiel, und kopiert eine einzelne Datei nach Web:. Dabei muß es sich nicht unbedingt um ein HTML-Dokument handeln. Alles, was der Browser anzeigen kann, gilt, also auch Bilder.

"Wget page with images" holt eine einzelne Seite mit all ihren Bildern.

Und "Wget site" schließlich kopiert die ganze Verzeichnisstruktur, ausgehend vom aktuellen Verzeichnis am Server, wobei Daten-Ramsch wie Archive und Musikdaten weggelassen werden.

Während die ersten beiden Macros in der Regel unproblematisch sind, kommt es beim Spiegeln einer ganzen Site bekanntlich fast immer zu Problemen. Deshalb ist es meist notwendig, ein paar zusätzliche Optionen anzugeben. Nun will man aber nicht ein jedesmal die Preferences von IBrowse ändern wollen.

Aus diesem Grund kann man dem Script ein paar "eigene" Optionen übergeben, die nicht an Wget weitergereicht werden. Die einzige für uns wichtige heißt Ask und läßt einen Requester erscheinen, in dem wir die Optionen für Wget angeben können. Damit können wir noch folgende Eintrag machen:

Name	Macro
Wget site...	wget.rexx Ask --recursive --convert-links --no-parent --reject=mpg,mpeg,wav,au,aiff,aif,tgz,Z,gz,zip,lha,lzx,ps

Wie leicht zu erkennen ist, sind die restlichen übergebenen Optionen identisch zu "Wget site". Vom Namen her unterscheidet er sich durch die drei Punkterl am Ende. Ein Menüeintrag, der mit Punkterl endet, bezeichnet ja bekanntlich eine Operation, die noch weitere Eingaben erfordert - und genau das ist bei hier ja der Fall.

Ausgabe im Browser

Hat man die Scripts wie oben eingebunden, und startet man sie vom Rexx-Menü des Browsers aus, so wird normalerweise automatisch ein CLI geöffnet, in dem Wget seine Ausgaben machen kann.

Wie das konkret aussehen soll, entnimmt IBrowse aus Preferences/General/General/Output Window. Dort sollte ein Wert wie

CON:0/0/640/200/IBrowse Output/AUTO/WAIT/CLOSE/SCREEN%p

stehen. Wichtig ist das /WAIT/CLOSE, da dadurch das CLI-Fenster offen bleibt, auch wenn das Script beendet wurde, sodaß man sich eventuelle Fehlermeldungen in Ruhe ansehen kann.

In diesem Fenster kann man aber keine Befehle eingeben wie in einem normalen CLI, sondern nur auf das Close-Gadget klicken, wenn Wget fertig ist. Dennoch kann man auch weiterhin Control-C drücken, um das Script (und damit auch Wget) abzubrechen. (Im Falle von IBrowse hat das leider den Effekt, daß auch der ganze Browser beendet wird. AWeb zeigt in der Hinsicht wesentlich mehr Intelligenz.)

AWeb Anwender hingegen müssen die entsprechende Console beim Aufruf des Macros direkt angeben. Ansonsten würde alles "verschluckt" werden, ohne daß man jemals etwas von Wget sieht - obwohl es läuft. Um dem entgegen zu wirken, könnte der erste Macro lauten:

Name	Macro
Wget single resource	wget.rexx >CON://640/200/Wget.rexx/AUTO/CLOSE/WAIT

Weiters soll darauf hingewiesen werden, daß man die Ausgabe immer anhalten kann. Im etwas patscherten Standard-CLI z.B. durch einen Druck auf die Leertaste. Fortsetzen geht dann mit der Rücktaste (Backspace). Erweiterte CLI's wie KingCON oder ViNCEd bieten meistens ausgefeiltere Mechasnismen für "Halt & Resume", es sei auf deren Dokumentation verwiesen.

Das heißt also: Das Starten von Wget ist jetzt wesentlich komfortabler, und man kann sich einfach für jede persönlich relevante Sammlung von Optionen einen Menüeintrag machen. Dennoch ist es auch weiterhin notwendig, Wget zu beobachten. Abbrechen kann man wie vorher, und Weitermachen mit mehr Optionen zur Müllvermeidung geschieht eben mit dem Eintrag, der auch die Option Ask setzt.

Zur Erinnerung: Praktisch jeder von uns hat einen Systempatch installiert, der es ermöglicht, den Inhalt eines String-Requesters durch Druck auf Amiga-C bzw. Amiga-V durch das Clipboard zu jagen, was vor allem bei wiederholtem Verfeinern der Wget-Optionen von wget-ask.ibrx nützlich ist.

Wget automatisch starten

Kurz hingewiesen werden soll auch auf die Möglichkeit, Wget automatisch zu starten. Das hat natürlich nur Sinn, wenn man genau weiß, was man kriegen wird.

Manche FTP-Server sind unter Tags oft überlastet, und lassen Wget erst gar nicht einloggen. Man könnte folgendes kleine Shell-Script verfassen und z.B. als t:wget-zeix abspeichern:

wait until 23:30 wget ftp://ftp.überlastet.org/pub/zeix.lha

Startet man das Script im CLI mit

run execute t:wget-zeix

kann man gemütlich ins Kino gehen, und eine halbe Stunde vor Mitternacht beginnt Wget zu saugen. Das geht natürlich auch mit anderen, CLI-basierten FTP-Clients.

Als praktisch könnte es sich dabei erweisen, die Ausgabe von Wget in eine Datei umzulenken bzw. sich einer der beiden Optionen --output-file oder --append-output zu bedienen.

Die echten Profis erledigen derlei Dinge mit Utilities wie aminet:util/time/EZCron.lha.

Voraussetzung zu all dem ist natürlich, daß einem die Netzwerkverbindung nicht "pro Minute" kostet.

Und aus

Damit sind wir am Ende des Workshops angelangt. Fassen wir noch einmal zusammen:

Wget ist ein leistungsfähiges, aber kaum bedienbares Programm zum Kopieren von Daten aus dem WWW. Zum einen es es so konzipiert, daß es instabile Netzwerke und kurze Ausfälle nicht sonderlich beeindrucken. Zum anderen ermöglicht es, mit einem Aufruf ganze Verzeichnisstrukturen zu kopieren. Weil das etwas problematisch ist, sollte man es dabei nicht unbeobachtet lassen. Bei Bedarf gibt es etliche Optionen, um den Aktionsradius einzuschränken.

Um von der hinigen Technologie des Internets wegzukommen, haben wir unser eigenes Web: auf der lokalen Platte angelegt. Die selbstgefälligen Schulterklopfer rund um die Internet RFC's, die Hampelmänner des World Wide Web Consortiums und die für jede Online-Minute die Hand aufhaltenden Provider können uns damit bis zu einem gewißen Grad den Buckel runterrutschen.

Das muß ja nicht unbedingt bedeuten, das wir mit der Idee einer vernetzten Welt ein grundsätzliches Problem haben und uns deshalb lieber einem hemmungslosen Festplatten-Biedermaier hingegeben. Es kann einfach heißen, das wir mit einer in ihrem innersten verfaulten technologischen Müllhalde, wie es das Internet nun mal ist, so wenig wie möglich zu tun haben wollen.

Was die traditionelle Unbedienbarkeit der Programmen von Unix-Männer betrifft: an ein paar Dinge haben wir uns halt seufzend angepaßt, dabei aber im Hinterkopf behalten, daß man es besser machen kann. Die unüberschaubare Anzahl von CLI-Optionen haben wir in ein paar ARexx-Macros verpackt, die wir von unserem Browser aus per Mausklick starten. Und die paar oft benötigten Optionen, die man braucht, um Wget von bestimmten Daten abzuhalten, können wir dann leicht im Kopf behalten - und sie auch wirklich anwenden.

Und alles was man dazu braucht ist ein Amiga und ein bisserl Hirn. Aber beides, wohlgemerkt.

Thomas Aglassinger ...........

Workshop Teil 1

wget.rexx - ARexx-Script, um Wget vom Browser aus zu starten

aminet:comm/www/WgetRexx.lha - Archiv mit dem ARexx-Script.

Workshop Teil 2

aminet:util/rexx/rexxdossupport.lha - Archiv mit ein den Libraries für zum Parsen der CLI-Argumente.

aminet:util/libs/ReqToolsUsr.lha - Archiv mit ein den Libraries für den Requester.

....