Wget - Surfen einmal anders (Teil 2)

Überblick

Im ersten Teil dieses Workshops haben wir uns mit der für Amiganer seltsam anmutenden Installation und grundsätzlichen Bedienung beschäftigt. Zusätzlich wurden ein paar Features bezüglich instabiler Verbindungen und Besorgen von Daten auf FTP-Servern besprochen.

Diesmal geht es um jene Funktion von Wget, die am meisten verwendet wird: dem Kopieren von Seiten im WWW.

Dazu werden ein paar konkrete Anwendungen beschrieben, und die Optionen, die dazu nötig sind. Die allgemeine Vorgehensweise dabei ist folgende: Anfangs werden so wenig Optionen wie möglich verwendet, um das ganze übersichtlicher zu gestalten. In der Regel zeigen sich dann aber einige Probleme oder Einschränkungen, die mit Hilfe ein paar weiterer Optionen behoben werden.

Daher sollte man einen Abschnitt zu Ende gelesen werden, bevor man einzelne Beispiele ausprobiert.

Aus der reinen Anwendersicht wird diesmal folgendes besprochen: einzelne Seiten besorgen, eine Seite mit Bildern kopieren, Probleme rekursiven Saugens und ganz viele Seiten saugen.

Einzelnen Seiten besorgen

Will man nur ein paar einzelne Seiten oder Dateien haben, so kann man analog zum Aufruf für FTP einfach die URL als Parameter angeben. Zum Beispiel hat da ein netter Mensch ein Seite gemacht, die zu Dokumenten verweist, die Bildformate beschreiben. Um die ins aktuellen Verzeichnis des CLI zu kopieren reicht ein simples

wget http://www.dcs.ed.ac.uk/home/mxr/gfx/2d-hi.html

Die neue Datei hat den Namen 2d-hi.html, wie nicht anders zu erwarten. Gibt man eine URI an, die mit einem Schrägstrich endet, so entscheidet der Server am anderen Ende, wie das Dokument heißt, das geschickt wird. Üblicherweise kriegt es den Namen index.html oder welcome.html. Im Zweifelsfalle werfe man einen Blick auf die Ausgabe von Wget.

Man beachte, daß die URI diesmal mit http:// beginnt, und nicht wie im letzten Teil, mit ftp://. Trotzdem ist das ganze natürlich nicht auf .html Dateien beschränkt, man kann genau so Bilder, Archive und alles anderer saugen. Will man z.B. die das Archiv der ersten Ausgabe der AmigaScene haben, so so bietet sich folgender Aufruf dazu an:

wget http://www.amigascene.com/amigascene_01.lha

Es können auch mehrere Adressen gleichzeitig angegeben werden, um z.B die ersten beiden Ausgaben zu besorgen:

wget http://www.amigascene.com/amigascene_01.lha http://www.amigascene.com/amigascene_02.lha

Übrigens werden Text- und Binärdateien nicht unterschiedlich behandelt. Das heißt, es wird keine Übersetzung von CR/LF in LF (oder gar umgekehrt) durchgeführt. Das ist angenehm wenn die MIME-Types des Servers falsch oder unvollständig konfiguriert sind, was bekanntlich häufig vorkommt.

Wer jetzt nur Bahnhof verstanden hat: Die praktische Auswirkung von obiger Tatsache ist, daß LHA-Archive beim Download nicht "kaputtkonvertiert" werden - im Gegensatz zu zahlreichen kommerziellen Browsern bzw. Servern.

Eine Seite mit Bildern kopieren

Zuvor haben wir ein einzelnes Dokument kopiert. Das Original enthält aber einige kleine Bilder, die zwar nicht den Informationsgehalt steigern, die Seite aber gefälliger aussehen lassen. Was tun, wenn in unserer Kopie die Bilder auch enthalten sein sollen?

Zum Glück kann Wget in einem Dokument enthaltene Verweise und Bilder "weiterverfolgen". Prinzipiell reicht dazu folgender Aufruf:

wget --recursive --level=1 http://www.dcs.ed.ac.uk/home/mxr/gfx/2d-hi.html

Das --recursive bewirkt, daß alle anderen Daten, auf die von dieser Seite aus verwiesen wird, auch geholt werden. Das gilt sowohl für HTML-Seiten, in der Seite enthaltene Bilder als auch für alles andere, was ein Link ist. Oft sieht man Verweise auf Animationen, Musikdaten oder einer druckbaren Version der Seite im Postscriptformat. Hält man Wget nicht davon ab, wird auch das alles geholt.

Diese Option hat aber noch eine weitere Auswirkung, wenn eine Seite auf eine weitere HTML-Seiten verweist. Die neue Seite wird nicht nur kopiert, sondern wiederum nach weiteren Verweisen untersucht. Danach wird natürlich auch diese Material besorgt - und so weiter, und so weiter.

In unserem Fall ist das nicht sinnvoll, weil wir nur die Sachen von genau dieser einen Seite haben wollen. Darum wird mit --level=1 gesagt, daß nach einer Generation von HTML-Seiten abgebrochen werden soll. Das kommt dem, was wir wollen, schon ziemlich nahe.

Wer sich den Seite etwas genauer betrachtet wird aber merken, daß sie auf viele andere Seiten verweist, die uns jetzt gar nicht interessieren. Wir wollen ja nur die Einstiegsseite haben, was durchaus Sinn macht. Denn damit können wir "zu Hause" entscheiden, ob es sich lohnt, ins Netz zu gehen, wenn wir Dokumentation zu einem Bildformat brauchen.

Also sagen wir Wget, daß es sich bei seinen Aktionen auf den Ausgangserver www.dcs.ed.ac.uk beschränken soll. Genau das macht die Option --domains. Der verbesserte Aufruf lautet dann also:

wget --recursive --level=1 --domains=www.dcs.ed.ac.uk http://www.dcs.ed.ac.uk/home/mxr/gfx/2d-hi.html

Nun kann es aber wie bereits weiter oben angedeutet durchaus sein, daß diese Seite auch auf lokale Daten verweist, die uns nicht interessieren. Wir wollen ja nur die Bilder haben. Dazu kann man Wget veranlassen, nur Dateien mit einer bestimmten Endung in Betracht zu ziehen. Die im WWW üblichen Bildformate sind ja bekanntlich PNG, JFIF/JPEG und GIF. Diese Namen ergeben meist auch die Endung des Dateinamens. Da JPEG zu viele Buchstaben für dumme Systeme enthält, werden solche Dateien oft mit der Endung .jpg gespeichert.

Man braucht Wget also nur die entsprechenden Endungen mit der Option --accept anzugeben, wobei sie durch Beistriche zu trennen sind. Leerzeichen sind nicht erlaubt, da sonst angenommen wird, daß es sich hier bereits um die nächste Option handelt. Alles, was eine Endung hat, die nicht im Argument zu --accept enthalten ist, wird unterdrückt. Der weiter verfeinerte Aufruf lautet also:

wget --recursive --level=1 --accept=png,jpg,jpeg,gif --domains=www.dcs.ed.ac.uk http://www.dcs.ed.ac.uk/home/mxr/gfx/2d-hi.html

Gibt man dies im CLI ein, holt Wget wie gewollt die Seite und alle in ihr enthaltenen Bilder, sofern sie am selben Server liegen. Weil es sich diesmal nicht um eine einzelne Datei handelt, wird auch die Verzeichnisstruktur des Servers angelegt. Mehr sogar, es wird ein eigenes Verzeichnis für den Server www.dcs.ed.ac.uk angelegt - mit eben diesem Namen. Konkret erhalten wir also folgende Dateien:

www.dcs.ed.ac.uk/home/mxr/gfx/2d-hi.html www.dcs.ed.ac.uk/home/mxr/gfx/img/back-marble.jpg www.dcs.ed.ac.uk/home/mxr/gfx/img/ball1.gif www.dcs.ed.ac.uk/home/mxr/gfx/img/ball2.gif www.dcs.ed.ac.uk/home/mxr/gfx/img/line-rainbow.gif www.dcs.ed.ac.uk/robots.txt

Nun können wir in unserem WWW-Browser die lokale Datei www.dcs.ed.ac.uk/home/mxr/gfx/2d-hi.html im Verzeichnis, von dem aus Wget gestartet wurde, ansehen. Dazu gibt es in jedem WWW-Browser eine Funktion wie "Lokale Datei öffnen".

Roboten gehn

Wenn wir uns die Ausgabe von Wget bei dem obigen Aufruf genauer ansehen, stoßen wir auf folgenden Eintrag, der etwas verwirrt:

Loading robots.txt; please ignore errors. --11:22:24-- http://www.dcs.ed.ac.uk:80/robots.txt => `www.dcs.ed.ac.uk/robots.txt' Connecting to www.dcs.ed.ac.uk:80... connected! HTTP request sent, fetching headers... done. Length: 1,733 [text/plain]

Huch, wer ist denn robots.txt? Den wollen wir doch gar nicht, wozu geben wir sonst unser einschränkendes --accept an?

Wget ist offensichtlich kein WWW-Browser, da die Seiten damit nicht angezeigt und gelesen werden können. Wget ist ein sogenannter WWW-Robot, der automatisch Seiten durchstöbert, und, wie eben wir gesehen haben, davon ausgehend rekursiv weitere Daten anfordern kann.

Ein anderes Beispiel für so einen Robot sind die Programme, die dafür sorgen, daß Suchmaschinen wie Altavista halbwegs aktuell bleiben. Stark vereinfacht gesagt analysieren solche Robots den Text einer Seite, merken sich die gefundenen Stichwörter und tragen diese in eine großen, dicken Datenbank ein.

Robots tun zwar auf den ersten Blick das gleiche wie ein Browser, trotzdem unterscheiden sie sich in einige Dinge. Zum Beispiel "lesen" Robots Seiten viel schneller als Menschen, wählen ihre Links dafür aber auch "unüberlegter" aus. Üblicherweise ließt ein Robot alles, was er findet. Das heißt, daß Robots für einen Server eine größere Belastung sind und ein weitaus höheres Datenaufkommen bewirken als menschliche Leser.

Zusätzlich lesen Robots auch Daten, die sich ständig ändern, die keine nennenswerte Information für sie enthalten (z.B. CGI-Scripts) oder nur in einer anderen Form bereits gelesene Information (z.B. eine Frames/NoFrames Version einer Seite).

Manch ein Informationsanbieter möchte daher gewiße Robots von bestimmten Teilen seines Serves fernhalten. Und genau das kann er mit dem Anlegen eines robots.txt machen. Die Details dazu sind für uns nicht relevant, weil sich WGet ganz alleine darum kümmert, und normalerweise nichts tut, was ihm robots.txt verbietet.

In den vielen Fällen existiert ein solches robots.txt aber gar nicht. Leider wird dies von Wget trotzdem mit einer für den Anwender mehr verwirrenden statt informativen Meldung gehandhabt. Auf einem anderen Server könnte sich z.B. folgendes in der Ausgabe zeigen:

Loading robots.txt; please ignore errors. --13:23:39-- http://www.adac-com.com:80/robots.txt => `www.adac-com.com/robots.txt' Connecting to www.adac-com.com:80... connected! HTTP request sent, fetching headers... done. 13:23:42 ERROR 404: Not Found.

Sinnvollerweise sollte in so einem Fall gar nichts ausgegeben werden. Um das ganze für den Anwender noch undurchsichtiger werden zu lassen, wird im "non-verbose" Modus mit -nv gar nur ERROR 404: Not Found. ausgegeben, ohne ein Wort darüber zu verschwenden, daß es sich um robots.txt handelt.

Das ist offensichtlich wieder eine jener Unix-Traditionen: ein Programm muß so konzipiert sein, daß es nur ja keine vernünftigen Fehlermeldungen ausgibt. Wenn überhaupt, dann so, daß keiner weiß, was gemeint ist. Und natürlich ist die Programmstruktur auch konsequent so gehalten, daß sich eine besserer Fehlerbehandlung kaum nachrüsten läßt, ohne das ganze Programm umzukrempeln. Den Aufwand macht sich aber nie jemand, weil es einfacher ist, sich nachträglich "anzupassen" anstatt gleich etwas vernünftiges zu programmieren.

Fassen wir also zusammen: Sobald --recursive gesetzt ist, versucht Wget auch das robots.txt zu lesen. Für einzelne Dateien betrachtet sich Wget nicht als Robot, sondern als Browser, was auch durchaus Sinn macht.

Die Sache mit robots.txt ist aber nicht so, daß es sich hier um eine tolle Verwaltung von Zugriffsrechten handelt. Das Ganze muß vom Robot (hier eben Wget) unterstützt werden. Wie alles, was mit WWW zu tun hat, ist auch hier das Konzept eine grausliche Improvisiererei, und robots.txt kann nicht viel mehr sagen als "Bitte nicht", ein "Verboten!" ist damit nicht möglich.

Mehr dazu gibt es auf der Homepage des Robots Exclusion Standards (RES).

HTML verweigern?

Eine weitere kleine Ungereimtheit von Wget im Zusammenhang von --accept ist das Verweigern von HTML-Dateien. Da wir zuvor ein --accept=png,jpg,jpeg,gif hatten, sollten alles das mit .html endet, verweigert werden.

Das ist aber nicht notwendigerweise sinnvoll, vor allem wenn --level einen Wert größer eins hat. HTML-Dateien werden also in jedem Fall geholt und nach weiteren Links untersucht, auch wenn man sie nicht in --accept angibt.

Wenn wir uns aber die obige Liste der erhaltenen Dateien noch einmal ansehen, finden wir kein www.dcs.ed.ac.uk/home/mxr/gfx/3d-hi.html, obwohl von unserem 2d-hi.html darauf verwiesen wird. Ein genaueres Betrachten der Ausgabe von Wget liefert aber die Klärung der Angelegenheit:

Removing www.dcs.ed.ac.uk/home/mxr/gfx/3d-hi.html since it should be rejected.

Die Datei wurde also gesaugt, analysiert und danach wieder gelöscht. Mit --level=1 macht das wirklich nicht viel Sinn, bei höheren Werten aber durchaus. So könnte man leicht von einer tief verschachtelten Seitensammlung alle Bilder kopieren, ohne danach viele HTML-Dateien herumliegen zu haben, indem man einfach den Wert für --level entsprechend anpasst.

Faulheit

Natürlich sind wir Amiganer alle faule Säcke, und wollen nicht ein jedesmal die ganze lange Wurst von oben angeben, wenn wir eine Seite zusammen mit ihren Bildern speichern wollen.

Ein Unix-Mann würde uns jetzt sagen: "Selber schuld, warum nehmt ihr auch die lange Version der CLI-Optionen", und statt

wget --recursive --level=1 --accept=png,jpg,jpeg,gif --domains=www.dcs.ed.ac.uk http://www.dcs.ed.ac.uk/home/mxr/gfx/2d-hi.html

ein

wget -rl1 -Apng,jpg,jpeg,gif -Dwww.dcs.ed.ac.uk http://www.dcs.ed.ac.uk/home/mxr/gfx/2d-hi.html

machen. Und nach drei Minuten weiß er selbst nicht mehr, was dieser Aufruf eigentlich macht. Wir sind natürlich schlauer, und schreiben ein kleines Rexx-Script, daß uns diese Arbeit abnimmt. Und sagen dann nur noch:

rx wget-page.rexx http://www.dcs.ed.ac.uk/home/mxr/gfx/2d-hi.html

Dieses Script ist nämlich hinterhältig genug, den Server www.dcs.ed.ac.uk auch gleich an die Option --domains zu übergeben. Dem ARexx-Interessierten wird klar sein, daß es kein großes Problem darstellt, den Servernamen aus einer vollständigen URI herauszufiltern. Folgende Zeile macht genau das:

/* Extract the name of the WWW-server to be downloaded from */ PARSE VAR options . 'http://' server '/' .

Alle anderen können das Script natürlich auch anwenden, ohne sich über derlei Dinge Gedanken machen zu müssen, könnten aber im Hinterkopf behalten, daß manche Dinge oft leichter zu automatisieren sind als man zuerst denkt.

Und weil wir Amiganer nicht ganz stur sind und vom Unix-Mann durchaus was gelernt haben, kopieren wir das Script nach SYS:Rexx und verpassen der s:Shell-startup folgenden Eintrag:

alias wget-page rx SYS:Rexx/wget-page.rexx

Ab jetzt sagen nur mehr:

wget-page http://www.dcs.ed.ac.uk/home/mxr/gfx/2d-hi.html

Natürlich können diesem Script zusätzlich alle anderen Optionen für Wget übergeben werden. So könnte man z.B. das Märchenerzählen wie im letzten Teil beschrieben mit -nv (non-verbose) unterbinden:

wget-page -nv http://www.dcs.ed.ac.uk/home/mxr/gfx/2d-hi.html

Der Unix-Mann hätte wahrscheinlich ein Perl-Script geschrieben, das das gleiche macht. Nur könnte er aufgrund der obskuren Perl-Syntax drei Minuten später wieder nicht mehr sagen, was es macht, hätte natürlich unausprechlich wgpg.pl genannt, keine Fehlerbehandlung für den Fall eines vergessenen oder falschen Wertes für die URI programmiert und nicht daran gedacht, denn Rückgabewert von Wget an die Außenwelt zu liefern, falls jemand auf die Idee kommen könnte, sein Script aus einem anderen Script zu starten und wissen will, ob alles geklappt hat. Das alles, um der Tradition zu entsprechen.

Ein Glück, daß wir es besser wissen, obwohl wir genau so faul sind.

Probleme rekursiven Saugens

Leute, die nicht viel nachdenken, könnten jetzt glauben, daß man dann nur folgendes einzutippen braucht:

wget --recursive --level=9999 http://www.yahoo.com/

Tolle Sache, dann braucht man nur eine Festplatte mit einer Größe von paar Terrabyte (AmigaOS kann mit sowas inzwischen ja umgehen) und ein paar Jahre Zeit, und schon hat man einen großen Teil des WWW bei sich zu Hause. Oder?

Erstens ist das nicht der Fall, da Wget ein paar Mechanismen eingebaut hat, um das Datenaufkommen nicht ausarten zu lassen, und zweitens ist es nicht der Sinn der Sache, hemmungslos alles zu Saugen was ansatzweise interessant scheinen könnte.

Gerade für Amiganer ist die Versuchung groß, da viele unter dem Problem "leiden", daß es heutzutage keine sinnvoll kleinen Festplatten mehr gibt. Und man plötzlich mit 2 GB dasteht, obwohl 500 MB locker gereicht hätten.

Aus diesem Grund gibt es jetzt in der Tradition schlechter amerikanischer SitComs die moralischen zwei Minuten. Danach darf wieder gelacht werden.

Oft ist es gar nicht notwendig, eine ganze Site rekursiv zu saugen. Einfach deshalb, weil Autoren ihre Information bereits in ein Archive gepackt haben und auf ihrer Seite bereitstellen.

In einem solchen Fall wird in der Regel bereits auf der Einstiegsseite auf dieses Service hingewiesen. Mit ein bißchen guten Willen ist so etwas normalerweise nicht zu übersehen. Derlei Archive benötigen nur einen Verbindungsaufbau und sind durch die Kompression um einiges kleiner als alle Seiten einzeln - und schneller geht es außerdem.

Und wenn es einmal nicht LHA ist, so soll das nicht schrecken. Sowohl für ZIP und TGZ gibt es für Amiga entsprechende Utilities. Das Aminet oder die Download-Page des Amigascene sind bei der Beschaffung derselben sehr hilfreich.

Ein weiteres Problem ist, daß viele Seiten ein Copyright haben, und man sie nicht so ohne weiteres kopieren darf, auch wenn es technische leicht mögliche ist - wie wir ja in diesem Workshop sehen.

Unabhängig davon sind aus dem Web kopierte Daten in keinem Fall in öffentlich zugänglichen Bereichen zu speichern ohne den Autor davon zu verständigen.

Das Problem besteht darin, daß Leute unsere Kopie finden könnten, ohne zu wissen, wo das Original ist. Wenn die Kopie nun aber schon veraltert ist und Fehler enthält, die im Original auf den Seiten des Autors schon längst behoben sind, dann ist das ziemlich schlecht. Sowohl für den Autor als auch den Benutzer.

Daher: Mit Wget besorgte Daten nie auf Netzwerkplatten ablegen, sondern immer in einem nur für den Anwender selbst zugänglichen Bereich.

Jetzt aber genug der Zeigefingerwachelei und wieder zurück zu WGet und seinen Optionen.

Ganz viele Seiten saugen

Im Beispiel zuvor haben wir zwei Mechanismen verwendet, um die Auswirkungen von --recursive einzuschränken: --level=1, um nur eine kleine Rekursionstiefe zu haben, und dann auch --domains, um Verweise auf andere Server zu ignorieren.

Was tun, wenn man eine ganze Verzeichnisstruktur kopieren will?

Zuerst kann man natürlich --level auf einen höheren Wert setzen. Dann funktioniert aber in der Regel die Sache mit --domains nicht mehr. Denn viele Seiten verweisen auf ganz andere Daten von anderen Leuten am selben Server, an denen wir meistens überhaupt nicht interessiert sind.

Wir wollen wieder von einem konkreten Beispiel ausgehen. So gibt es die beliebte Band "Half Man Half Biscuit" (HMHB), die vor allem für ihre Texte bekannt sind. In diesen wimmelt es in der Regel nur so von Anspielungen und Querverweisen, die kaum alle geistig erfaßbar sind. Aus diesem Grund gibt es eine HMHB Homepage, die versucht, diese Dinge aufzulösen.

So findet sich zu der Textzeile "Who's afraid of Virginia Wade" aus dem Lied "Outbreak of Vitas Gerulaitis" vom Album "McIntyre, Treadmore and Davitt" folgender Eintrag:

Virginia Wade Nasal voiced English tennis player, coincidental winner of Wimbledon ladies championship in 1977, year of the Silver Jubilee. Virginia Woolf was an abused-as-a-child lesbian novelist who wrote classic though rather dull books. Who's Afraid of Virginia Woolf is over-rated crap which I think starred Richard Burton and Elizabeth Taylor.

Weil HMHB viele Lieder und viele Alben gemacht haben, die alle ähnlich anspruchsvoll sind, wollen wir jetzt das ganze Material von der Homepage bei uns daheim haben.

Eine einfache und gleichzeitig leistungsfähige Möglichkeit, Wget einzuschränken, ist die Option --no-parent. Diese bewirkt nämlich, daß Verzeichnisse "oberhalb" des Ausgangsverzeichnisses ignoriert werden. Also brauchen wir im Grunde nur zu sagen:

wget --recursive --no-parent http://www.btinternet.com/~hmhb/hmhb.htm

Das funktioniert auch schon ganz gut, und wir lehnen uns zurück und beobachten, was Wget so alles an Land zieht:

www.btinternet.com/%7Ehmhb/hmhb.htm www.btinternet.com/%7Ehmhb/images/hmhb1.jpg www.btinternet.com/%7Ehmhb/images/Q94s2.jpg www.btinternet.com/%7Ehmhb/News.htm : viele, viele Dateien :

Zuerst fällt einmal auf, daß in Dateinamen unserer lokalen Kopie die Tilde (~) durch ein kryptisches %7E ersetzt wird. Wie nicht anders zu erwarten handelt es sich hier einmal mehr um eine Unix-Tradition, nur daß diesmal eine vollständige Erklärung zu lange und belanglos für den Amiganer ist.

Die Kurzversion ist, daß die Tilde in Unix ein gescheiterter Versuch ist, eine vergleichbare Funktionalität wie die unserer Assigns zur Verfügung zu stellen. Weil aber das Konzept der Unix-Tilde vollkommen krank ist, funktioniert es die meiste Zeit nicht und verwirrt erfolgreich viele Programme, wenn man sie trotzdem verwendet. Dennoch haben sich die Unixler eingebildet, daß die Tilde auch in URIs verwendet werden muß, obwohl das die URI-Spezifikation nicht vorsieht. Wget macht mit einer Tilde daher das einzig Sinnvolle: es schmeißt sie raus bzw. ersetzt sie durch ihren ASCII-Code im Hexadezimalformat - wie es die URI-Spezifikation auch haben will. Das schaut zwar komisch aus, funktioniert dafür aber sogar unter Unix.

Jetzt ist es aber an der Zeit, wieder einen Blick auf unser fröhlich dahinwerkendes Wget zu werden. Daß tut auch bitter Not, den nach einer Weile erscheinen eine Menge Daten, die uns zuvor beim durchblättern nicht aufgefallen sind und alle in einem Verzeichnis namens fallnet liegen:

www.btinternet.com/%7Ehmhb/fallnet/fallnet.htm www.btinternet.com/%7Ehmhb/fallnet/fallnet.gif www.btinternet.com/%7Ehmhb/fallnet/gez97/Tom_mes2.jpg www.btinternet.com/%7Ehmhb/fallnet/djohn/C2.jpg www.btinternet.com/%7Ehmhb/fallnet/djohn/C1.jpg

Offensichtlich sind das meiste davon Bilder, die eine unangenehme Eigenschaft haben: sie sind groß und haben daher eine hohe Netzwerkbelastung. Wir sehen uns daher das entsprechende http://www.btinternet.com/~hmhb/fallnet/fallnet.htm in unserem Browser etwas genauer an.

Nach kurzem Nachforschen stellt sich heraus, daß der Mann, der die HMHB-Seiten macht, auch einiges anderes Zeug hier herumliegen hat. Und zwar sind eben im Verzeichnis /~hmhb/fallnet jede Menge Bilder von betrunkenen Leuten bei verschiedenen Konzerten der beliebten Band "The Fall", die bekanntlich auch schwierige Texte haben. Das ist aber eine anderer Geschichte, und vor allem interessieren uns jetzt die Fotos von Englands größten Alkoholikern wenig.

Also brechen wir den Datentransfer ab. Wie im CLI üblich durch einen beherzten Druck auf Control-C.

Offensichtlich müssen wir unsere Anfrage noch etwas genauer angeben. In diesem Zusammenhang erweißt sich die Option --exclude-directories als nützlich. Damit können wir als Argument eine Liste von Verzeichnisnamen übergeben, die ignoriert werden sollen. Wie bei --accept werden mehrer Einträge durch einen Beistrich getrennt.

In unserem Fall reicht es aber, nur ein Verzeichnis anzugeben, also:

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

Folgender Aufruf hat aber den Nachteil, daß alle Daten, die wir bereits erfolgreich gesaugt haben, noch einmal geholt werden. Bei FTP hatten wir im letzten Teil ein ähnliches Problem, das wir mittels --continue-ftp gelöst haben. Für HTTP gibt es die Option --no-clobber, die bewirkt, daß bei existierenden HTML-Datein diese nicht nocheinmal besorgt werden, sondern die lokale Kopie verwendet wird.

Im Unterschied zu --continue-ftp wird aber eine halbfertige HTML-Datei nicht fortgesetzt, also aufpassen. Um ganz sicher zu gehen, kann man der Ausgabe von Wget die zuletzt bearbeitete Datei entnehmen, und diese mit der Hand löschen, bevor man mit einem erneuten Aufruf von Wget fortsetzt.

In unserem Fall bedeutet dies, daß wir nach einem

delete fallnet all

folgendes sagen:

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

Wget bestätigt uns, daß viele Dateien bereits vorhanden sind und nicht erneut geholt werden. Danach wird dort fortgesetzt, wo wir zuletzt abgebrochen haben, und die Welt ist wieder in Ordnung.

Ein Problem das sich jedoch stellt ist, daß im Fall der HMHB Homepage die Rekursionstiefe zu gering ist. Gibt man nichts an, wird der Wert automatisch auf --level=5 gesetzt. Man merkt beim Ansehen der lokalen Kopie, daß ein paar Bilder fehlen. Da wir inzwischen mit --no-clobber vertraut sind, ist das kein Problem mehr:

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

Damit scheint es, daß wir endlich alles haben, was wir wollten. Das ist aber nur bedingt richtig, den möglicherweise haben wir sogar mehr.

Müllvermeidung

Fast stolze 200k macht nämlich ein Datei mit der Endung .wav aus. Auf der ganzen HMHB-Site gibt es zur Zeit der Entstehung dieses Artikels nur genau eine solche Datei, und eigentlich ist sie sogar interessant zu hören, weil es sich um einen Auszug aus einem bösartigen Interview handelt.

Trotzdem ist es oft schön, wenn gewiße Dateien nicht kopiert werden. Das betrifft vor allem Musikdaten, Animationen, Postscript oder komprimierte Archive.

Von zuvor kennen wir schon --accept. Diese Option hat einen Bruder namens --reject, der oft praktischer ist. Denn hat man viele verschiedene Dateitypen, wird es schnell langweilig, diese mit --accept anzugeben. Zumal weiß man oft nicht genau, was einem erwartet, aber man weiß, was man nicht will.

Unsere ursprüngliche Anweisung zum Kopieren der HMHB-Seite könnte also gelautet haben:

wget --recursive --level=9 --no-parent --reject=wav,au,aiff,aif --exclude-directories=/~hmhb/fallnet http://www.btinternet.com/~hmhb/hmhb.htm

Dies unterdrückt so ziemlich alle Arten von Tondaten.

Fortgeschrittenen Anwendern sei die Originaldokumentation von Wget empfohlen, da sich --accept und --reject auch kombinieren lassen. Weiters kann man anstatt von Dateiendungen auch Muster angeben, womit sich dann einiger Unsinn anstellen läßt. Es hat aber vermutlich wenig Sinn, den Normalverbraucher damit zu konfrontieren.

Der hier vorgestellte Ansatz, nämlich simples Verwenden von Endungen mit entweder --accept oder --reject, sollte leicht zu merken sein, und senkt das Datenaufkommen bereits erheblich.

Faulheit, die zweite

Weil wir in den letzten Absätzen nicht viel fleißiger geworden sind, packen wir den ganzen Vorgang wieder in ein Rexx-Script und nennen es wget-site.rexx. Der zugehörige Eintrag in s:Shell-startup lautet logischerweise:

alias wget-site rx sys:rexx/wget-site.rexx

Ein kurze Betrachtung wert ist folgende Zeile gegen Anfang des Scripts:

/* File extensions indicating data we won't need */ trash = 'mpg,mpeg,wav,au,aiff,aif,tgz,Z,gz,zip,lha,lzx,ps'

Hier werden einfach alle Dateiendungen angegeben, an denen wir üblicherweise nicht interessiert sind. Bei Bedarf kann diese Liste erweitert (oder gekürzt) werden. Der Tippaufwand des schiefgegangenen ersten Versuchs zum Saugen von HMHB reduziert sich damit auf:
wget-site http://www.btinternet.com/~hmhb/hmhb.htm

Und das Fortsetzen mit Ausschließen des bösen Alkoholikerverzeichnisses sieht so aus:

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

Diesmal sollten wir vielleicht doch auf den Unix-Mann hören, und uns die Kurzformen merken, da derlei Fälle häufig auftreten:

wget-site -nc -X /~hmhb/fallnet http://www.btinternet.com/~hmhb/hmhb.htm

Die letzten beiden Aufrufe haben somit dieselbe Wirkung. Dennoch sollte innerhalb es ARexx-Scripts oder CLI-Aliases immer die Langform verwendet werden, damit man später, wenn etwas geändert werden soll, noch weiß, was hier geschieht.

Wie es weitergeht

Wir wissen jetzt, wie man ganze Verzeichnisse aus dem WWW kopieren kann. Und wir wissen auch, daß dabei einiges zu beachten ist. Es empfiehlt sich, Wget bei Rekursionen nicht unbeobachtet zu lassen, da immer es wieder passiert, daß Daten auftauchen, die man nicht erwartet hätte.

Zum Glück hält sich sich der Aufwand in Grenzen, Wget abzubrechen und mit --no-clobber und paar Optionen zur Einschränkung des Aktionsradius neu zu starten.

Damit ist die eigentliche Leistungsfähigkeit (und auch Problematik) von Wget zum Großteil erörtert. Im nächsten Teil werden daher nur noch ein paar einzelne Optionen besprochen, die die Sache noch angenehmer machen können. Weiters wird die Funktion der Konfigurationsdatei .wgetrc behandelt. Als besonders Zuckerl werden die ARexx-Scripts so erweitert, daß sie sofort vom Browser aus benutzbar sind und wir uns vom CLI verabschieden können.

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

wget-page.rexx - ARexx-Script zum Saugen einer Seite mit ihren Bildern
wget-site.rexx - ARexx-Script zum Saugen einer ganzen Verzeichnisstruktur, mit Ausschluß "unnützer" Daten Workshop Teil 1
Robots Exclusion Standards - Details zu robots.txt
Half Man Half Biscuit - Die Homepage mit Interpretationshilfen der Liedtexte

....