Hi, ich verwende wget in einem Script um ein Backup vom Sourceforge Server zu ziehen. Leider hat mir in der Mailing Liste dort noch niemand geantwortet. Manchmal bricht das Script beim Download ab und ich habe eine kaputte Datei. Es liegt in /etc/cron.weekly Was kann ich besser machen ? #!/bin/sh D=`/bin/date +%F` F=lbdmf-cvsroot.tar.bz2 wget http://cvs.sourceforge.net/cvstarballs/$F mv $F /home/lothar/lbDMF-Backup/lbdmf-cvsroot-$D.tar.bz2 chown lothar.users /home/lothar/lbDMF-Backup/lbdmf-cvsroot-$D.tar.bz2 -- Lothar Behrens | Rapid Prototyping ... Rosmarinstr 3 | 40235 Düsseldorf | www.lollisoft.de
Am Mittwoch, 9. November 2005 15:10 meinte Lothar Behrens: Hallo Lothar,
ich verwende wget in einem Script um ein Backup vom Sourceforge Server zu ziehen.
Manchmal bricht das Script beim Download ab und ich habe eine kaputte Datei.
Es liegt in /etc/cron.weekly
Was kann ich besser machen ?
#!/bin/sh D=`/bin/date +%F` F=lbdmf-cvsroot.tar.bz2 wget http://cvs.sourceforge.net/cvstarballs/$F mv $F /home/lothar/lbDMF-Backup/lbdmf-cvsroot-$D.tar.bz2 chown lothar.users /home/lothar/lbDMF-Backup/lbdmf-cvsroot-$D.tar.bz2
Ich wuerde das File erst dann verschieben [1], wenn es komplett da ist. Die Rechte wuerde ich erst aendern, wenn das File auch fehlerfrei verschoben ist. wget -c http://cvs.sourceforge.net/cvstarballs/$F && \ mv $F /~/lbDMF-Backup/lbdmf-cvsroot-$D.tar.bz2 && \ chown lothar.users /~/lbDMF-Backup/lbdmf-cvsroot-$D.tar.bz2 An den Optionen fuer wget wuerde ich noch feilen. (man wget) [1] Warum schreibst Du das File eigentlich nicht gleich an die richtige Stelle? #!/bin/bash woher="http://www.von.hier.de" wohin="/dev/null" # :-) wget -c "$woher" -nH --directory-prefix="$wohin" && machnochwas MfG Th. Moritz -- Wissen ist Macht! Nichts wissen macht auch nichts, ...
Hallo, Am Wed, 09 Nov 2005, Thomas Moritz schrieb: [..]
[1] Warum schreibst Du das File eigentlich nicht gleich an die richtige Stelle?
#!/bin/bash woher="http://www.von.hier.de" wohin="/dev/null" # :-) wget -c "$woher" -nH --directory-prefix="$wohin" && machnochwas
woher="http://www.von.hier.de/foo-1.2.3.bar.baz" ###### Vorbereitung ###### ### Variante GNU Bash: wohin="${woher##*\/}"; ## basename "$wohin" in bash wohin="${wohin//.bar.baz/}_v$(date '+%F').bar.baz" ### Variante GNU basename: wohin="$(basename "$woher" '.bar.baz')_v$(date '+%F').bar.baz" ###### Download ###### ### Variante '&&' '||': wget -c -O "$wohin" "$woher" \ && { machnochwas; und noch mehr } \ || { retval=$?; echo "So ein Mist, wget kann $woher nicht saugen" >&2; echo "ODER machnochwas und noch mehr hat nicht geklappt" >&2; exit $retval; } ### Variante 'if-then-else-fi': if wget -c -O "$wohin" "$woher"; then machnochwas und noch mehr else retval=$? echo "So ein Mist, wget kann '$woher' nicht saugen" >&2 exit $retval fi Der Hauptunterschied sind die einfacheren Moeglichkeiten zur Fehlerbehandlung in der if-then-else-fi Variante. Bei der '&&-||' muss man diese wiederum schachteln oder dort dann if..fi einbauen, und das wird dann schnell unuebersichtlich. Wenn man also das "machnochwas" usw. mehr als ein Befehl ist (plus Fehlerbehandlung) und dies nicht in eine Funktion auslagert empfiehlt sich eindeutig die "if-then-else-fi" Variante. Andererseits ist eben, in einfachen Faellen, die "&&-||" Variante kurz und praegnant und gut lesbar. Insbesondere in einfachen Faellen, die ins Schema Befehl || Fehlermeldung passen mach ich das gerne. z.B.: test -r ~/.foorc && . ~/.foorc || { echo "cannot read ~/.foorc" >&2; exit 1; } Dabei faengt das || { .. } sowohl Fehler beim 'test -r' ab als auch Fehler beim eigentlichen Lesen der Datei mit source ("."). Vgl.: $ false && ( exit 42; ) || echo "$?" 1 ^^^^^^^^^wird nicht ausgefuehrt, exitcode von false ist 1. Fehlermeldung ("echo $?") reagiert auf's "false" $ true && ( exit 42; ) || echo "$?" 42 ^^^^^^^^^wird ausgefuehrt, da exitcode von true ist 0 Fehlermeldung ("echo $?") reagiert auf's "exit 42" Achso, bevor's untergeht: ich wollte v.a. die Option '-O' von wget hervorheben: wget -O AUSGABEDATEI URL BTW: DIE Dokumentation von wget ist 'info wget'(!). Und dann waere da noch 'curl' als Alternative zu wget, aber das kann kein "continue" ohne Nachhilfe (Angabe eines Offsets, wenn ich die Ausgabe von --help richtig lese). Und allein das disqualifiziert 'curl' IMHO schon. -dnh PS: Auf meiner "ex-SuSE 6.2" hab' ich curl 7.12, auf der SuSE 9.1 nur 7.11 (und auch noch ohne "Largefile"-Support). *hehe*
Am Mittwoch, 9. November 2005 21:59 meinte David Haller: Hallo David,
Am Wed, 09 Nov 2005, Thomas Moritz schrieb: [..]
[1] Warum schreibst Du das File eigentlich nicht gleich an die richtige Stelle?
#!/bin/bash woher="http://www.von.hier.de" wohin="/dev/null" # :-) wget -c "$woher" -nH --directory-prefix="$wohin" && machnochwas
### Variante 'if-then-else-fi': if wget -c -O "$wohin" "$woher"; then machnochwas und noch mehr else retval=$? echo "So ein Mist, wget kann '$woher' nicht saugen" >&2 exit $retval fi
Du warst so ausfuehrlich:-) Dann sollte aber die case-Variante nicht fehlen: case "`wget -c $woher -O $wohin`$?" in 0) echo "hat geklappt"; echo "machnochwas";; 1) echo "ging schief"; echo "machs nochmal";; *) echo "Ende mit Fehlercode=$?";; esac Das hat den Vorteil, dass man bei Programmen mit mehreren definierten ReturnCodes auf jeden beliebigen entsprechend reagieren kann. (schoen uebersichtlich) Im Beispiel bin ich nur von 0=OK 1=!OK ausgegangen. Hatte gerade keine Lust mit wget rumzuspielen:-) PS.: Die Option -O von wget hatte ich mir nie angewoehnt, da sie nur bei 1-File-Downloads (wie hier vom OP gesucht) sinnvoll ist. Der zu schreibende FileName ist hierbei zwingend erforderlich. Mein Standard ist eher folgender Aufruf:-) wget -r -c "$woher" -nH --directory-prefix="$wohin" --cut-dirs=x (bei grossen Sachen kommt noch ein --dont-remove-listing hinzu) MfG Th. Moritz -- Wieso haben so viele Maenner einen Bierbauch? Das der arbeitslose Zwerg ein Dach ueberm Kopf hat:-)
Hallo, Am Fri, 11 Nov 2005, Thomas Moritz schrieb:
Am Mittwoch, 9. November 2005 21:59 meinte David Haller: [..] Du warst so ausfuehrlich:-) Dann sollte aber die case-Variante nicht fehlen:
case "`wget -c $woher -O $wohin`$?" in 0) echo "hat geklappt"; echo "machnochwas";; 0) echo "hat geklappt"; echo "machnochwas";; 1) echo "ging schief"; echo "machs nochmal";; *) echo "Ende mit Fehlercode=$?";; esac
*HUCH*[tm]!!!! Dascha ein Konstrukt, dass ich noch gar nicht kenne! Schon besser. Aber zum korrekt Variablen quoten musst du noch paranoider werden! Besser: case `wget -c -O "$wohin" "$woher"` in ... Die "" um die `` scheinen nicht noetig zu sein (auch nicht bei der ash), und da $? keine Strings mit wilden Werten zurueckliefert... Ebenso das $? nach den ``. Ausserdem solltest du dich an die Reihenfolge "Programm [OPTIONEN] [ARGUMENTE]" halten, d.h. das '-O bla' ist eine Option (mit deren Argument) und das "$woher" ist das Argument. Eine andere Reihenfolge geht oft, aber nicht immer(!), mit GNU Utils gut, mit anderen Utils faellst du aber schnell auf die Schnauze. Man sollte sich also sowohl das "paranoide" quoten von Variablen usw., als auch eine paranoide Reihenfolge von "Erst Optionen, dann Argumente" angewoehnen. Ja, ich mach das auf der Kommandozeile auch nicht immer, wenn eine laengere Befehls-Zeile nach und nach entsteht -- in Scripten bin ich aber (inzwischen) sorgfaeltig.
Das hat den Vorteil, dass man bei Programmen mit mehreren definierten ReturnCodes auf jeden beliebigen entsprechend reagieren kann. (schoen uebersichtlich)
Jup. Ist z.B. bei antivir praktisch.
Im Beispiel bin ich nur von 0=OK 1=!OK ausgegangen. Hatte gerade keine Lust mit wget rumzuspielen:-)
AFAIK liefert wget keine anderen Exitcodes.
PS.: Die Option -O von wget hatte ich mir nie angewoehnt, da sie nur bei 1-File-Downloads (wie hier vom OP gesucht) sinnvoll ist. Der zu schreibende FileName ist hierbei zwingend erforderlich.
Jup. Hier aber IMHO angebracht ;)
Mein Standard ist eher folgender Aufruf:-)
wget -r -c "$woher" -nH --directory-prefix="$wohin" --cut-dirs=x (bei grossen Sachen kommt noch ein --dont-remove-listing hinzu)
Meiner:
cd "$dir_wos_hinsoll" && wget -m -k -np [-nr] "$woher"
bzw.:
cd /wo/hin/ && machwas | wget -m -k -np -i -
Achso: '-c' ist natuerlich ggfs. auch dabei!
Insbesondere das '-i'-Feature von wget ist extrem praktisch wenn man
z.B. Webcomics schluerft und per printf o.ae. zusammenbastelt... Oder
auch nur gewisse URLs eben in einer Datei aufhebt... ;) curl kann das
wohl nicht. *hurhur*
Und dann hab ich noch ein paar 'wget-as-*' shell-aliase, die wget mit
einer passenden '-U' Option aufrufen, z.B.:
wget-as-mozilla is aliased to `wget -U "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021130"'
Und es gibt tatsaechlich Seiten, die ein ehrliches 'wget' ablehnen, bei
denen man mit dem 'wget-as-mozilla' dann aber doch problemlos saugen
kann...
-dnh
--
Linux renders ships, NT is rendering ships useless.
-- apparently Robert Riggs
Am Montag, 14. November 2005 06:44 meinte David Haller: Hallo David,
Am Fri, 11 Nov 2005, Thomas Moritz schrieb:
Am Mittwoch, 9. November 2005 21:59 meinte David Haller:
[..]
Du warst so ausfuehrlich:-) Dann sollte aber die case-Variante nicht fehlen:
case "`wget -c $woher -O $wohin`$?" in 0) echo "hat geklappt"; echo "machnochwas";; 1) echo "ging schief"; echo "machs nochmal";; *) echo "Ende mit Fehlercode=$?";; esac
*HUCH*[tm]!!!! Dascha ein Konstrukt, dass ich noch gar nicht kenne!
Geht trotzdem gut:-)
Schon besser. Aber zum korrekt Variablen quoten musst du noch paranoider werden! Besser:
Ich hab aber garkein kaputtes Filesystem mit kranken Filenamen:-) Nun habe ich mir auf einen Zettel geschrieben: "Ab morgen werde ich paranoid skripten" Das lese ich jetzt jeden Tag:-)
case `wget -c -O "$wohin" "$woher"` in ...
Die "" um die `` scheinen nicht noetig zu sein (auch nicht bei der ash), und da $? keine Strings mit wilden Werten zurueckliefert... Ebenso das $? nach den ``.
Ausserdem solltest du dich an die Reihenfolge "Programm [OPTIONEN] [ARGUMENTE]" halten, d.h. das '-O bla' ist eine Option (mit deren Argument) und das "$woher" ist das Argument.
Eine andere Reihenfolge geht oft, aber nicht immer(!), mit GNU Utils gut, mit anderen Utils faellst du aber schnell auf die Schnauze.
Du hast ja voellig recht! Ich teste mein Zeuchs erst in der bash und anschliessend in der ash! Der Tip kam, so glaube ich zumindest, vor langer Zeit mal von Dir. Wenn es irgendwelche Probleme gibt, dann setze ich "set -xv" statt dem ueblichen "set -e" und sehe wo es klemmt.
Man sollte sich also sowohl das "paranoide" quoten von Variablen usw., als auch eine paranoide Reihenfolge von "Erst Optionen, dann Argumente" angewoehnen.
Ja, ich mach das auf der Kommandozeile auch nicht immer, wenn eine laengere Befehls-Zeile nach und nach entsteht -- in Scripten bin ich aber (inzwischen) sorgfaeltig.
Dahin komme ich hoffentlich auch noch...
Das hat den Vorteil, dass man bei Programmen mit mehreren definierten ReturnCodes auf jeden beliebigen entsprechend reagieren kann. (schoen uebersichtlich)
Jup. Ist z.B. bei antivir praktisch.
uvm.
Mein Standard ist eher folgender Aufruf:-)
wget -r -c "$woher" -nH --directory-prefix="$wohin" --cut-dirs=x (bei grossen Sachen kommt noch ein --dont-remove-listing hinzu)
Meiner:
cd "$dir_wos_hinsoll" && wget -m -k -np [-nr] "$woher"
bzw.:
cd /wo/hin/ && machwas | wget -m -k -np -i -
Achso: '-c' ist natuerlich ggfs. auch dabei!
Insbesondere das '-i'-Feature von wget ist extrem praktisch wenn man z.B. Webcomics schluerft und per printf o.ae. zusammenbastelt... Oder auch nur gewisse URLs eben in einer Datei aufhebt... ;) curl kann das wohl nicht. *hurhur*
Mit curl verschicke ich lediglich die eingehenden Anrufe quer durch's Haus. Da brauche ich nicht erst zum Telefon zu gehen oder vom Fernsehsessel aufzustehen, wenn mich die Nummer nicht interessiert:-)
Und es gibt tatsaechlich Seiten, die ein ehrliches 'wget'
Hast Du ein anderes 'wget' als ich? :-)))
ablehnen, bei denen man mit dem 'wget-as-mozilla' dann aber doch problemlos saugen kann...
Jaja, ich muss manchmal auch in meiner 'wgetrc' eine Zeile auskommentieren. MfG Th. Moritz -- Zahlreiche Senioren verschwinden spurlos im Internet, weil sie unbedacht "Alt" und "Entf" druecken! [aus de.alt.fan.aldi]
Hallo David, hallo Thomas, hallo Leute, Am Montag, 14. November 2005 06:44 schrieb David Haller:
Am Fri, 11 Nov 2005, Thomas Moritz schrieb:
case "`wget -c $woher -O $wohin`$?" in 0) echo "hat geklappt"; echo "machnochwas";; 0) echo "hat geklappt"; echo "machnochwas";; 1) echo "ging schief"; echo "machs nochmal";; *) echo "Ende mit Fehlercode=$?";; esac
*HUCH*[tm]!!!! Dascha ein Konstrukt, dass ich noch gar nicht kenne!
Ich würde es auch nicht empfehlen. Grund: es schlägt fehl, sobald das aufgerufene Programm irgendwas auf stdout schreibt. Hier ein (zugegebenermaßen offensichtliches) Beispiel: case "`echo foo`$?" in 0) echo "hat geklappt"; ;; 1) echo "ging schief"; ;; *) echo "irgendwas: $?"; ;; esac Ergebnis: "irgendwas: 0" (ja, die 0 ist wirklich noch der Exitcode vom echo-Befehl. Wer es nicht glaubt, probiert es mit "echo foo ; false" statt nur echo ;-) Besser, weil nicht anfällig gegen stdout: echo foo ; case $? in [Rest wie oben] Gruß Christian Boltz -- Nicht nur Schoenheit, sondern auch Schweinkram liegt ausschliesslich im Auge des Betrachters. [Kristian Koehntopp zur Aussage "frauen sind gut zu voegeln" in http://groups.google.com/groups?selm=3ejajb$ekj@picard.toppoint.de]
Christian Boltz wrote:
Hallo David, hallo Thomas, hallo Leute,
Am Montag, 14. November 2005 06:44 schrieb David Haller:
Am Fri, 11 Nov 2005, Thomas Moritz schrieb:
case "`wget -c $woher -O $wohin`$?" in 0) echo "hat geklappt"; echo "machnochwas";; 0) echo "hat geklappt"; echo "machnochwas";; 1) echo "ging schief"; echo "machs nochmal";; *) echo "Ende mit Fehlercode=$?";; esac
*HUCH*[tm]!!!! Dascha ein Konstrukt, dass ich noch gar nicht kenne!
Ich würde es auch nicht empfehlen. Grund: es schlägt fehl, sobald das aufgerufene Programm irgendwas auf stdout schreibt.
Hier ein (zugegebenermaßen offensichtliches) Beispiel:
case "`echo foo`$?" in 0) echo "hat geklappt"; ;; 1) echo "ging schief"; ;; *) echo "irgendwas: $?"; ;; esac
Ergebnis: "irgendwas: 0" (ja, die 0 ist wirklich noch der Exitcode vom echo-Befehl. Wer es nicht glaubt, probiert es mit "echo foo ; false" statt nur echo ;-)
Besser, weil nicht anfällig gegen stdout:
echo foo ; case $? in [Rest wie oben]
Gruß
Christian Boltz
Hallo Christian, David und alle, die es interessiert! Christian, Du hast zwar recht damit, daß es nicht funktioniert, obwohl ich erst nicht damit übereinstimmte, aber der Grund ist ein anderer und es macht auch keinen Unterschied, ob das Programm etwas auf stdout schreibt oder nicht. Der Exitcode eines Programmes steht nur UNMITTELBAR NACH dem Kommando zur Verfügung. Es darf kein weiteres Kommando ausgeführt werden, welches einen Exitcode liefert, sonst kann für nichts garantiert werden (also selbst dann, wenn das folgende Kommando noch gar nicht fertig ist). Das bringt uns aber auch schon zur Lösung der Geschichte, denn der EINZIGE VERLÄSSLICH FUNKTIONIERENDE Weg für einen solchen Fall ist folgender: wget -c $woher -O $wohin RC=$? case $RC in 0) echo "hat geklappt"; echo "machnochwas";; 0) echo "Und dieser Casefall wird überhaupt nicht mehr ausgeführt"; echo "da der Fall 0 bereits abgearbeitet ist ...";; 1) echo "ging schief"; echo "machs nochmal";; *) echo "Ende mit Fehlercode=$RC";; esac Tjou, dann viel Spaß Martin P.S. ich habe noch ein kleines Skript angehängt, welches obiges einigermaßen nachvollziehbar demonstriert, wie ich meine: clear; echo testFile >testFile test -f testFile || ( echo "Konnte Datei 'testFile' nicht erstellen"; exit 1 ) echo "Type 1: false, true" tar H 2>/dev/null case `tar cvf testFile.tar testFile` in 0) echo "hat geklappt"; echo "machnochwas";; 1) echo "ging schief"; echo "machs nochmal";; *) echo "Ende mit Fehlercode=$?";; esac echo echo "Type 2: true, false" tar cvf testFile.tar testFile case `tar H 2>/dev/null` in 0) echo "hat geklappt"; echo "machnochwas";; 1) echo "ging schief"; echo "machs nochmal";; *) echo "Ende mit Fehlercode=$?";; esac echo echo "Type 3: false, true" tar H case `tar cvf testFile.tar testFile` in 0) echo "hat geklappt"; echo "machnochwas";; 1) echo "ging schief"; echo "machs nochmal";; *) echo "Ende mit Fehlercode=$?";; esac echo echo "Type 4: true, false" tar cvf testFile.tar testFile case `tar H` in 0) echo "hat geklappt"; echo "machnochwas";; 1) echo "ging schief"; echo "machs nochmal";; *) echo "Ende mit Fehlercode=$?";; esac echo echo "Type 5: true, irrelevant" true RC=$? case $RC in 0) echo "hat geklappt"; echo "machnochwas";; 0) echo "Und dies wird überhaupt nicht mehr ausgeführt, da der Fall 0 bereits abgearbeitet ist ...";; 1) echo "ging schief"; echo "machs nochmal";; *) echo "Ende mit Fehlercode=$RC";; esac echo echo "Type 6: false, irrelevant" false RC=$? case $RC in 0) echo "hat geklappt"; echo "machnochwas";; 0) echo "Und dies wird überhaupt nicht mehr ausgeführt, da der Fall 0 bereits abgearbeitet ist ...";; 1) echo "ging schief"; echo "machs nochmal";; *) echo "Ende mit Fehlercode=$RC";; esac
Am Dienstag, 15. November 2005 11:01 meinte Martin Deppe: Hallo Martin,
Christian Boltz wrote:
Hallo David, hallo Thomas, hallo Leute,
Der Exitcode eines Programmes steht nur UNMITTELBAR NACH dem Kommando zur Verfügung. Es darf kein weiteres Kommando ausgeführt werden, welches einen Exitcode liefert, sonst kann für nichts garantiert werden (also selbst dann, wenn das folgende Kommando noch gar nicht fertig ist).
Das bringt uns aber auch schon zur Lösung der Geschichte, denn der EINZIGE VERLÄSSLICH FUNKTIONIERENDE Weg für einen solchen Fall ist folgender:
wget -c $woher -O $wohin RC=$?
So ist's gut.
case $RC in 0) echo "hat geklappt"; echo "machnochwas";; 0) echo "Und dieser Casefall wird überhaupt nicht mehr ausgeführt"; echo "da der Fall 0 bereits abgearbeitet ist ...";;
Die zweite 0) hat David reingeschummelt:-) Die gab es bei mir nicht.
1) echo "ging schief"; echo "machs nochmal";; *) echo "Ende mit Fehlercode=$RC";; esac
Da habe ich ja was verzapft... Obwohl ich die *) Zeile erst kurz vor dem Versenden gedankenlos hinzugefuegt habe. Geschrieben ist geschrieben und meinen Senf habe ich weg *Duck*. MfG Th. Moritz -- Aufgeblasene Menschen leben staendig in Angst vor spitzen Bemerkungen.
Hallo Thomas, Thomas Moritz wrote:
Am Dienstag, 15. November 2005 11:01 meinte Martin Deppe:
Hallo Martin,
Christian Boltz wrote:
wget -c $woher -O $wohin RC=$?
So ist's gut.
case $RC in 0) echo "hat geklappt"; echo "machnochwas";; 0) echo "Und dieser Casefall wird überhaupt nicht mehr ausgeführt"; echo "da der Fall 0 bereits abgearbeitet ist ...";;
Die zweite 0) hat David reingeschummelt:-) Die gab es bei mir nicht.
sowas hab' ich mir schon gedacht ;-)
1) echo "ging schief"; echo "machs nochmal";; *) echo "Ende mit Fehlercode=$RC";; esac
Da habe ich ja was verzapft... Obwohl ich die *) Zeile erst kurz vor dem Versenden gedankenlos hinzugefuegt habe. Geschrieben ist geschrieben und meinen Senf habe ich weg *Duck*.
kein Problem! Hauptsache ist doch, daß es jetzt funktioniert oder ;-) ? Und ich habe mir mein Wissen auch wieder etwas aufgemöbelt, ist schon 'n Weilchen her, daß ich das Zeugs gemacht habe. Gruß Martin
Hallo, Am Tue, 15 Nov 2005, Thomas Moritz schrieb:
Am Dienstag, 15. November 2005 11:01 meinte Martin Deppe: [..]
case $RC in 0) echo "hat geklappt"; echo "machnochwas";; 0) echo "Und dieser Casefall wird überhaupt nicht mehr ausgeführt"; echo "da der Fall 0 bereits abgearbeitet ist ...";;
Die zweite 0) hat David reingeschummelt:-) Die gab es bei mir nicht.
Sorry, da hat sich beim zurechtloeschen/ergaenzen der Mail die eine Zeile verdoppelt. -dnh -- Ich springe so oft aus dem Fenster, daß ich ein schnurloses Telefon habe. [Ratti in suse-linux]
Hallo, Am Sun, 13 Nov 2005, Philipp Thomas schrieb:
Am 9 Nov 2005 21:59:31 +0100 schrieb David Haller:
### Variante GNU basename: wohin="$(basename "$woher" '.bar.baz')_v$(date '+%F').bar.baz"
Das hättest du auch bei der Variante Bash nehmen können, denn AFAIK ist basename bei der Bash eingebaut.
Nein. $ help basename bash: help: no help topics match `basename'. Try `help help'. $ type -a basename basename is /bin/basename basename is /usr/bin/basename $ bash --version GNU bash, version 2.03.0(1)-release (i386-suse-linux) Copyright 1998 Free Software Foundation, Inc # chroot /SUSE91 root@suse91:~# help basename bash: help: no help topics match `basename'. Try `help help' or `man -k basename' or `info basename'. root@suse91:~# type -a basename basename is /bin/basename basename is /usr/bin/basename root@suse91:~# bash --version GNU bash, version 2.05b.0(1)-release (i586-suse-linux) Copyright (C) 2002 Free Software Foundation, Inc. root@suse91:~# exit -dnh -- Der Mensch ist die Krone der Scjhöpfung. Jedoch setzt dies der Schöpfung nur zu oft die Krone auf. [Woko° in dafb]
Am 9 Nov 2005 21:59:31 +0100 schrieb David Haller:
PS: Auf meiner "ex-SuSE 6.2" hab' ich curl 7.12, auf der SuSE 9.1 nur 7.11 (und auch noch ohne "Largefile"-Support). *hehe*
Es bleibt aber dabei, dass derzeit nur curl mit Dateien umgehen kann, die grösser als 2 GB sind. Philipp
Philipp Thomas wrote:
[...] Es bleibt aber dabei, dass derzeit nur curl mit Dateien umgehen kann, die grösser als 2 GB sind.
Also, so ganz verstehe ich das nicht. Ich habe neulich unter Fedora Core 4 mit wget eine Datei heruntergeladen, die war definitiv >2GB. Und IIRC hat das ohne Probleme funktioniert (oder mein Gedaechtnis laesst mich gerade im Stich). Kann es sein, dass es Patches fuer wget gibt, die bei SuSE nicht enthalten sind? CU, Th.
Am Sonntag, 13. November 2005 13:09 schrieb Thomas Hertweck:
Philipp Thomas wrote:
[...] Es bleibt aber dabei, dass derzeit nur curl mit Dateien umgehen kann, die grösser als 2 GB sind.
Also, so ganz verstehe ich das nicht. Ich habe neulich unter Fedora Core 4 mit wget eine Datei heruntergeladen, die war definitiv >2GB. Und IIRC hat das ohne Probleme funktioniert (oder mein Gedaechtnis laesst mich gerade im Stich). Kann es sein, dass es Patches fuer wget gibt, die bei SuSE nicht enthalten sind?
CU, Th.
Das kann gut sein. Vielleicht hilft der Hinweis hier weiter: http://suse-linux-faq.koehntopp.de/faq-single.html#q-suse93-wget Gruß Herbert
Herbert Albert wrote:
Am Sonntag, 13. November 2005 13:09 schrieb Thomas Hertweck:
Philipp Thomas wrote:
[...] Es bleibt aber dabei, dass derzeit nur curl mit Dateien umgehen kann, die grösser als 2 GB sind.
Also, so ganz verstehe ich das nicht. Ich habe neulich unter Fedora Core 4 mit wget eine Datei heruntergeladen, die war definitiv >2GB. Und IIRC hat das ohne Probleme funktioniert (oder mein Gedaechtnis laesst mich gerade im Stich). Kann es sein, dass es Patches fuer wget gibt, die bei SuSE nicht enthalten sind?
Das kann gut sein. Vielleicht hilft der Hinweis hier weiter: http://suse-linux-faq.koehntopp.de/faq-single.html#q-suse93-wget
Ich lese dort: "Grund für diese Änderung ist, dass wget, wenn es mit Largefile-Unterstützung compiliert wird, bei Verwendung eines Proxys extrem lange für Downloads braucht. SuSE hat sich daher entschieden, die Largefile-Unterstützung wieder zu entfernen." Das kann ich absolut nicht bestaetigen. Der oben angesprochene Download (es war ein DVD Image mit 4.3GB) wurde ueber einen Proxy heruntergeladen (alle Verbindungen gehen bei uns ueber einen Proxy und der hat sich in der Vergangenheit nicht mal unbedingt als sehr kooperativ erwiesen) und hat ca. 2.5h gebraucht. Das halte ich fuer ordentlich und wuerde ich nicht als "braucht extrem lange fuer Downloads" bezeichnen ;-) Vielleicht ist Fedora ja einfach besser... ;-) *duck & renn* Cheers, Th.
Hallo Thomas, hallo Leute, Am Sonntag, 13. November 2005 14:27 schrieb Thomas Hertweck:
Herbert Albert wrote:
Am Sonntag, 13. November 2005 13:09 schrieb Thomas Hertweck:
Philipp Thomas wrote:
[...] Es bleibt aber dabei, dass derzeit nur curl mit Dateien umgehen kann, die grösser als 2 GB sind.
Also, so ganz verstehe ich das nicht. Ich habe neulich unter Fedora Core 4 mit wget eine Datei heruntergeladen, die war definitiv >2GB. Und IIRC hat das ohne Probleme funktioniert (oder mein Gedaechtnis laesst mich gerade im Stich). Kann es sein, dass es Patches fuer wget gibt, die bei SuSE nicht enthalten sind?
Das kann gut sein. Vielleicht hilft der Hinweis hier weiter: http://suse-linux-faq.koehntopp.de/faq-single.html#q-suse93-wget
Ich lese dort: "Grund für diese Änderung ist, dass wget, wenn es mit Largefile-Unterstützung compiliert wird, bei Verwendung eines Proxys extrem lange für Downloads braucht. SuSE hat sich daher entschieden, die Largefile-Unterstützung wieder zu entfernen."
Das war zumindest die Zusammenfassung aus dem zugehörigen Bugreport.
Das kann ich absolut nicht bestaetigen. Der oben angesprochene Download (es war ein DVD Image mit 4.3GB) wurde ueber einen Proxy heruntergeladen (alle Verbindungen gehen bei uns ueber einen Proxy und der hat sich in der Vergangenheit nicht mal unbedingt als sehr kooperativ erwiesen) und hat ca. 2.5h gebraucht. Das halte ich fuer ordentlich und wuerde ich nicht als "braucht extrem lange fuer Downloads" bezeichnen ;-) Vielleicht ist Fedora ja einfach besser... ;-) *duck & renn*
*nachrenn* *hab dich!* ;-) Welche wget-Version hast Du denn? Die problematische Version war wohl ein CVS-snapshot (20041113), bei dem LargeFile-Support (LFS) noch recht experimentell war. Die 9.3 kam dann mit 1.9.1 ohne LFS. In SUSE 10.0 (wget 1.10.1) ist LargeFile-Support laut rpm -q --changelog wget wieder drin. Gruß Christian Boltz -- Und ja, verdammt nochmal, das Web ohne Flash und Movies ist unbrauchbar, langweilig und Scheisse. Wenn ich wollte, dass es schwarzweiss ist und nicht zappelt, würde ich ein Buch lesen. [Ratti in suse-linux
Christian Boltz wrote:
Am Sonntag, 13. November 2005 14:27 schrieb Thomas Hertweck:
[...] Das kann ich absolut nicht bestaetigen. Der oben angesprochene Download (es war ein DVD Image mit 4.3GB) wurde ueber einen Proxy heruntergeladen (alle Verbindungen gehen bei uns ueber einen Proxy und der hat sich in der Vergangenheit nicht mal unbedingt als sehr kooperativ erwiesen) und hat ca. 2.5h gebraucht. Das halte ich fuer ordentlich und wuerde ich nicht als "braucht extrem lange fuer Downloads" bezeichnen ;-) Vielleicht ist Fedora ja einfach besser... ;-) *duck & renn*
*nachrenn* *hab dich!* ;-)
Hatte ich Dir schon erzaehlt, dass ich die 10km in ca. 38 bis 40min renne? *g* (jedenfalls vor meinem Muskelfaserriss)
Welche wget-Version hast Du denn?
Nun, das System, von dem oben die Rede ist, ist ein Standard FC4 mit handelsueblichen Updates (lediglich die base, extra und update repositories sind eingebunden). Die genaue Version kann ich Dir momentan nicht sagen, da ich nicht an jenem System sitze. Falls es Dich brennend interessiert, schau am Besten mal bei RedHat auf dem Server vorbei, da muesstest Du das entsprechende wget (FC4) finden ;-)
Die problematische Version war wohl ein CVS-snapshot (20041113), bei dem LargeFile-Support (LFS) noch recht experimentell war. Die 9.3 kam dann mit 1.9.1 ohne LFS.
In SUSE 10.0 (wget 1.10.1) ist LargeFile-Support laut rpm -q --changelog wget wieder drin.
Interessant. Warum hoert man dann so viele Klagen, dass wget nicht mit grossen Dateien umgehen kann? Oder sind diese Klagen schlicht "historisch" begruendet? Ich habe hier keine 10.0, bin privat immer noch bei meinen 8.2 und 9.2, kann daher keine Aussage zu "aktuellen" SuSE Distros machen. Cheers, Th.
Hallo, Am Sun, 13 Nov 2005, Thomas Hertweck schrieb:
Christian Boltz wrote:
Am Sonntag, 13. November 2005 14:27 schrieb Thomas Hertweck:
[...] Das kann ich absolut nicht bestaetigen. Der oben angesprochene Download (es war ein DVD Image mit 4.3GB) wurde ueber einen Proxy heruntergeladen [..] Vielleicht ist Fedora ja einfach besser... ;-) *duck & renn*
*nachrenn* *hab dich!* ;-)
Hatte ich Dir schon erzaehlt, dass ich die 10km in ca. 38 bis 40min renne? *g* (jedenfalls vor meinem Muskelfaserriss)
*autsch* [..]
Die problematische Version war wohl ein CVS-snapshot (20041113), bei dem LargeFile-Support (LFS) noch recht experimentell war. Die 9.3 kam dann mit 1.9.1 ohne LFS.
In SUSE 10.0 (wget 1.10.1) ist LargeFile-Support laut rpm -q --changelog wget wieder drin.
Interessant. Warum hoert man dann so viele Klagen, dass wget nicht mit grossen Dateien umgehen kann? Oder sind diese Klagen schlicht "historisch" begruendet?
Vermutlich.
Ich habe hier keine 10.0, bin privat immer noch bei meinen 8.2 und 9.2, kann daher keine Aussage zu "aktuellen" SuSE Distros machen.
*pfrt* Meine SuSE-Version sollte bekannt sein[0]. *g* Hm. Ich hab hier noch wget 1.7 (ich hab's irgendwann mal vom wget-1.5.3-57 der Distri aktualisiert) das AFAIR noch kein LFS kann. Ein kurzes strace bestaetigt das: $ LANG=C strace -eopen wget -q -O /dev/null http://localhost/ 2>&1 | grep '/dev/null' open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3 $ LANG=C strace -eopen curl -o /dev/null http://localhost/ 2>&1 | grep '/dev/null' open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4 # chroot /SUSE91/ root@suse91:~# LANG=C strace -eopen wget -q -O /dev/null http://localhost 2>&1 | grep '/dev/null' open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 3 root@suse91:~# LANG=C strace -eopen curl -o /dev/null http://localhost 2>&1 | grep '/dev/null' open("/dev/null", O_WRONLY|O_CREAT|O_TRUNC|O_LARGEFILE, 0666) = 4 wobei es jew. (u.a. erstmal) auf das O_LARGEFILE ankommt. (BTW: das curl/wget aus dem chroot greift auf den ausserhalb des chroot laufenden Apachen zu :) Mein "altes" curl macht's also richtig, das der 9.1 scheinbar auch, aber: $ curl --version curl 7.12.1 (i686-pc-linux-gnu) libcurl/7.12.1 OpenSSL/0.9.6 zlib/1.1.4 Protocols: ftp gopher telnet dict ldap http file https ftps Features: Largefile NTLM SSL libz root@suse91:~# curl --version curl 7.11.0 (i686-suse-linux) libcurl/7.11.0 OpenSSL/0.9.7d ipv6 zlib/1.2.1 Protocols: ftp gopher telnet dict ldap http file https ftps Features: IPv6 SSL libz NTLM Hm. Ich schreib mal wget auf die Liste der zu aktualisierenden Programme und koennte dann auch ins Changelog schauen ;) -dnh [0] Kleiner Hinweis fuer die, die's noch nicht oft genug gelesen haben: $ date -r /etc/SuSE-release Wed Sep 8 11:21:42 CEST 1999 -- Interpunktion und Orthographie des Postings ist frei erfunden. Eine Übereinstimmung mit aktuellen oder ehemaligen Regeln wäre rein zufällig und ist nicht beabsichtigt.
Hallo Lothar, hallo Ratti, hallo Leute, ^^^^^^^^^^^^ siehe weiter unten ;-) Am Mittwoch, 9. November 2005 15:10 schrieb Lothar Behrens:
ich verwende wget in einem Script um ein Backup vom Sourceforge Server zu ziehen. Leider hat mir in der Mailing Liste dort noch niemand geantwortet.
Manchmal bricht das Script beim Download ab und ich habe eine kaputte Datei.
Es liegt in /etc/cron.weekly
Was kann ich besser machen ? [...] wget http://cvs.sourceforge.net/cvstarballs/$F mv $F /home/lothar/lbDMF-Backup/lbdmf-cvsroot-$D.tar.bz2
wget ... && mv ... && ...
chown lothar.users /home/lothar/lbDMF-Backup/lbdmf-cvsroot-$D.tar.bz2
Wie wärs, den Cronjob als User laufen zu lassen? [1] Das erspart den chown-Aufruf und bringt nebenbei noch einen Sicherheitsgewinn. Zum eigentlichen Problem: Ratti hat das vor einiger Zeit auch schon beim Sichern des cvs-Tarballs der Fontlinge gehabt - es scheint an der Kombination sourceforge und cron zu liegen ;-) Manuell aufgerufen haben sowohl wget und curl den CVS-Tarball komplett runtergeladen, und nach einiger Zeit ging es auch wieder per cron. Vermutlich also ein Problem bei SF - mehr Details im Archiv von fontlinge-devel, Subject "Nightly Backup broken" im Juni/Juli 2005. @Ratti: Falls Du das liest - ist das Problem wieder da? Gruß Christian Boltz [1] Falls Du dennoch den cron.weekly-Mechanismus nutzen willst, melde Dich kurz bei mir. Ich habe ein Script hier, das ~/.cron.weekly usw. verwendet, bin aber noch nicht dazugekommen, es auf meine Homepage zu packen ;-) -- [checkinstall] is a tool that allows you to keep your brain in suspend mode. [Robert Schiele in opensuse]
Moin, Am Freitag, den 11.11.2005, 01:06 +0100 schrieb Christian Boltz:
Hallo Lothar, hallo Ratti, hallo Leute, ^^^^^^^^^^^^ siehe weiter unten ;-)
Mönsch, CC mich doch. Wer ahnt denn sowas! :-)
Am Mittwoch, 9. November 2005 15:10 schrieb Lothar Behrens:
ich verwende wget in einem Script um ein Backup vom Sourceforge Server zu ziehen. Leider hat mir in der Mailing Liste dort noch niemand geantwortet.
Manchmal bricht das Script beim Download ab und ich habe eine kaputte Datei.
Zum eigentlichen Problem: Ratti hat das vor einiger Zeit auch schon beim Sichern des cvs-Tarballs der Fontlinge gehabt - es scheint an der Kombination sourceforge und cron zu liegen ;-)
Jepp. Bei mir geht es inzwischen, allerdings ist das wohl nicht mein Verdienst. Plötzlich und unerwartet... klappte kein einziger Download des Backups mehr. Zum Einsatz kamen nacheinander curl, wget, lynx und lwp-download, keiner hat funktioniert. Von Hand aufgerufen lief alles problemlos. Niemand anders konnte mein Problem nachvollziehen. Der download lief jedesmal an, wurde aber immer an anderer Stelle gekappt. MAchmal fast sofort, manchmal kurz vor Ende, meistens mittendrin. Ich habe den cronjob mehrfach in der Uhrzeit verschoben, nix ging. Wochenlang. Von einem Tag auf den anderen ging es dann wieder - und seitdem ohne Probleme: FILE=/disk2/_fontlinge_nightly/fontlinge_`date "+%Y_%m_%d"`.tar.bz2 FROM=http://cvs.sourceforge.net/cvstarballs/fontlinge-cvsroot.tar.bz2 curl -o "$FILE" "$FROM" --retry 40 Sorry, keine Hilfe. Ich verstehe es selbst nicht. Gruß, Ratti -- -o) fontlinge | Fontmanagement for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
participants (9)
-
Christian Boltz -
David Haller -
Herbert Albert -
Joerg Rossdeutscher -
Lothar Behrens -
Martin Deppe -
Philipp Thomas -
Thomas Hertweck -
Thomas Moritz