Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[Linux] wget-log
29 views
Skip to first unread message
Andreas Kohlbach
Mar 6, 2020, 12:33:50 AM3/6/20
to
Ich finde in $HOME eine Menge wget-log*. Diese werden offenbar nur bei
Fehlern erstellt, okay.
Ich hätte sie lieber aber in /var/tmp, wo Dateien automatisch nach acht
Tagen Alters abgeräumt werden. Die man page nennt
logfile = file
für die wgetrc. Das scheint aber *eine* Datei zu erstellen, wo alle Logs
rein kommen. Kann man es einrichten, dass mehrere Dateien, wie derzeit in
$HOME zu finden, in /var/tmp angelegt werden?
--
Andreas
PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0
Fehlern erstellt, okay.
Ich hätte sie lieber aber in /var/tmp, wo Dateien automatisch nach acht
Tagen Alters abgeräumt werden. Die man page nennt
logfile = file
für die wgetrc. Das scheint aber *eine* Datei zu erstellen, wo alle Logs
rein kommen. Kann man es einrichten, dass mehrere Dateien, wie derzeit in
$HOME zu finden, in /var/tmp angelegt werden?
--
Andreas
PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0
Helmut Waitzmann
Mar 6, 2020, 10:39:05 AM3/6/20
to
Andreas Kohlbach <a...@spamfence.net>:
>Ich finde in $HOME eine Menge wget-log*. Diese werden offenbar
>nur bei Fehlern erstellt, okay.
Nein, je nach Einstellung nicht nur bei Fehlern.
>Ich hätte sie lieber aber in /var/tmp, wo Dateien automatisch
>nach acht Tagen Alters abgeräumt werden.
Das automatische Abräumen wäre ein Fehler. Mein System
beispielsweise läuft in der Regel länger als 8 Tage. Das Kommando
(
cd /var/tmp/ &&
exec find -H -- . ! -name . -mmin +"$((8*24*60))" \
! -exec env 'TIME_STYLE=+%Y-%m-%d' ls -QF1nod -- '{}' +
)
spuckt die Ausgabe:
prw------- 1 1001 0 2020-02-19 "./FvwmCommand-meersau:1.0C"|
prw------- 1 1001 0 2020-02-19 "./FvwmCommand-meersau:1.0M"|
prw------- 1 1000 0 2020-02-03 "./FvwmCommand-meersau:2.0C"|
prw------- 1 1000 0 2020-02-03 "./FvwmCommand-meersau:2.0M"|
Die zwei angemeldeten Benutzer würden dem Administrator in den
Hintern treten, wenn bei ihnen nach 8 Tagen der Fvwm nicht mehr
richtig funktionieren würde.
>Die man page nennt
>
>
>logfile = file
>
>für die wgetrc. Das scheint aber *eine* Datei zu erstellen, wo
>alle Logs rein kommen. Kann man es einrichten, dass mehrere
>Dateien, wie derzeit in $HOME zu finden, in /var/tmp angelegt
>werden?
Mit Hilfe der Konfigurationsdatei? Nicht, dass ich wüsste. Man
kann aber bei jedem Wget‐Aufruf mit den Optionen «-o» oder «-a»
festlegen, wohin das Log geht.
Die definitive Antwort sollte aber die Dokumentation (info) geben.
>Ich finde in $HOME eine Menge wget-log*. Diese werden offenbar
>nur bei Fehlern erstellt, okay.
>Ich hätte sie lieber aber in /var/tmp, wo Dateien automatisch
>nach acht Tagen Alters abgeräumt werden.
beispielsweise läuft in der Regel länger als 8 Tage. Das Kommando
(
cd /var/tmp/ &&
exec find -H -- . ! -name . -mmin +"$((8*24*60))" \
! -exec env 'TIME_STYLE=+%Y-%m-%d' ls -QF1nod -- '{}' +
)
spuckt die Ausgabe:
prw------- 1 1001 0 2020-02-19 "./FvwmCommand-meersau:1.0C"|
prw------- 1 1001 0 2020-02-19 "./FvwmCommand-meersau:1.0M"|
prw------- 1 1000 0 2020-02-03 "./FvwmCommand-meersau:2.0C"|
prw------- 1 1000 0 2020-02-03 "./FvwmCommand-meersau:2.0M"|
Die zwei angemeldeten Benutzer würden dem Administrator in den
Hintern treten, wenn bei ihnen nach 8 Tagen der Fvwm nicht mehr
richtig funktionieren würde.
>Die man page nennt
>
>
>logfile = file
>
>für die wgetrc. Das scheint aber *eine* Datei zu erstellen, wo
>alle Logs rein kommen. Kann man es einrichten, dass mehrere
>Dateien, wie derzeit in $HOME zu finden, in /var/tmp angelegt
>werden?
kann aber bei jedem Wget‐Aufruf mit den Optionen «-o» oder «-a»
festlegen, wohin das Log geht.
Die definitive Antwort sollte aber die Dokumentation (info) geben.
Helmut Waitzmann
Mar 6, 2020, 2:48:07 PM3/6/20
to
Andreas Kohlbach <a...@spamfence.net>:
>On Fri, 06 Mar 2020 16:38:45 +0100, Helmut Waitzmann wrote:
>
>> Andreas Kohlbach <a...@spamfence.net>:
>>> Die man page nennt
>>>
>>>
>>>logfile = file
>>>
>>> für die wgetrc. Das scheint aber *eine* Datei zu erstellen, wo
>>> alle Logs rein kommen. Kann man es einrichten, dass mehrere
>>> Dateien, wie derzeit in $HOME zu finden, in /var/tmp angelegt
>>> werden?
>>
>> Mit Hilfe der Konfigurationsdatei? Nicht, dass ich wüsste.
>> Man kann aber bei jedem Wget‐Aufruf mit den Optionen «-o» oder
>> «-a» festlegen, wohin das Log geht.
>
>Ich wollte das automatisch erledigt haben. Also nicht bei jedem
>Aufruf diese Option an die Kommando_Zeile übergeben.
>Kommando-Zeile nichts her, was sich automatisieren ließe.
Gibt sie das von dir beobachtete Verhalten, im HOME‐Verzeichnis
Dateien der Form wget-log* anzulegen, her?
>On Fri, 06 Mar 2020 16:38:45 +0100, Helmut Waitzmann wrote:
>
>> Andreas Kohlbach <a...@spamfence.net>:
>>> Die man page nennt
>>>
>>>
>>>logfile = file
>>>
>>> für die wgetrc. Das scheint aber *eine* Datei zu erstellen, wo
>>> alle Logs rein kommen. Kann man es einrichten, dass mehrere
>>> Dateien, wie derzeit in $HOME zu finden, in /var/tmp angelegt
>>> werden?
>>
>> Mit Hilfe der Konfigurationsdatei? Nicht, dass ich wüsste.
>> Man kann aber bei jedem Wget‐Aufruf mit den Optionen «-o» oder
>> «-a» festlegen, wohin das Log geht.
>
>Aufruf diese Option an die Kommando_Zeile übergeben.
>
>> Die definitive Antwort sollte aber die Dokumentation (info)
>> geben.
>
>/usr/share/info/wget.info.gz gibt außer der Angabe auf der
>> Die definitive Antwort sollte aber die Dokumentation (info)
>> geben.
>
>Kommando-Zeile nichts her, was sich automatisieren ließe.
Gibt sie das von dir beobachtete Verhalten, im HOME‐Verzeichnis
Dateien der Form wget-log* anzulegen, her?
Diedrich Ehlerding
Mar 7, 2020, 2:08:11 PM3/7/20
to
Andreas Kohlbach meinte:
> Es wird immer nur von *einer* Datei geschrieben. Nichts von einem
> Directory, wo das rein soll.
>
> Ich habe eben 20 Minuten in der Datei gelesen. Das kleine Ärgernis, dass
> alles in $HOME geloggt wird, ist es mir die Zeit nicht wert.
Das hiesige wget schreibt nur dann, wenn es im Hintergrnnd läuft, nach
"wget-log" und wenn das schon existiert nach "wget-log.<laufendenummer>".
Wenn es im Vordergrund läuft, schreib es nach stderr, wenn keine Option
"-o logfile" angegeben ist. Und es schreibt nicht nach $HOME, sondern nach
$PWD.
Kann es denn vorkommen, dass bei dir mehrere wgets parallel im selben $PWD
laufen? Wenn nicht, wäre in deinem Ablauf ein vorangehendes "cd /var/tmp/"
eine Alternative? Oder alternativ nach dem wget ein
"mv wget-log /var/tmp/wget-log.`date +%F-%T`" oder so ähnlich?
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.
> Es wird immer nur von *einer* Datei geschrieben. Nichts von einem
> Directory, wo das rein soll.
>
> Ich habe eben 20 Minuten in der Datei gelesen. Das kleine Ärgernis, dass
> alles in $HOME geloggt wird, ist es mir die Zeit nicht wert.
Das hiesige wget schreibt nur dann, wenn es im Hintergrnnd läuft, nach
"wget-log" und wenn das schon existiert nach "wget-log.<laufendenummer>".
Wenn es im Vordergrund läuft, schreib es nach stderr, wenn keine Option
"-o logfile" angegeben ist. Und es schreibt nicht nach $HOME, sondern nach
$PWD.
Kann es denn vorkommen, dass bei dir mehrere wgets parallel im selben $PWD
laufen? Wenn nicht, wäre in deinem Ablauf ein vorangehendes "cd /var/tmp/"
eine Alternative? Oder alternativ nach dem wget ein
"mv wget-log /var/tmp/wget-log.`date +%F-%T`" oder so ähnlich?
--
gpg-Key (DSA 1024) D36AD663E6DB91A4
fingerprint = 2983 4D54 E00B 8483 B5B8 C7D1 D36A D663 E6DB 91A4
HTML-Mail wird ungeleſen entſorgt.
Frank Miller
Mar 7, 2020, 8:00:23 PM3/7/20
to
Andreas Kohlbach wrote:
> On Fri, 06 Mar 2020 16:38:45 +0100, Helmut Waitzmann wrote:
>> Andreas Kohlbach <a...@spamfence.net>:
> On Fri, 06 Mar 2020 16:38:45 +0100, Helmut Waitzmann wrote:
>> Andreas Kohlbach <a...@spamfence.net>:
>>> Die man page nennt
>>>logfile = file
>>>
>>> für die wgetrc. Das scheint aber *eine* Datei zu erstellen, wo alle
>>> Logs rein kommen. Kann man es einrichten, dass mehrere Dateien, wie
>>> derzeit in $HOME zu finden, in /var/tmp angelegt werden?
>>
>> Mit Hilfe der Konfigurationsdatei? Nicht, dass ich wüsste. Man kann
>> aber bei jedem Wget‐Aufruf mit den Optionen «-o» oder «-a» festlegen,
>> wohin das Log geht.
>
>>>logfile = file
>>>
>>> für die wgetrc. Das scheint aber *eine* Datei zu erstellen, wo alle
>>> Logs rein kommen. Kann man es einrichten, dass mehrere Dateien, wie
>>> derzeit in $HOME zu finden, in /var/tmp angelegt werden?
>>
>> Mit Hilfe der Konfigurationsdatei? Nicht, dass ich wüsste. Man kann
>> aber bei jedem Wget‐Aufruf mit den Optionen «-o» oder «-a» festlegen,
>> wohin das Log geht.
>
> Ich wollte das automatisch erledigt haben. Also nicht bei jedem Aufruf
> diese Option an die Kommando_Zeile übergeben.
Mal ganz naive Idee (ich bin da nicht so ganz kundig): ließe sich nicht
> diese Option an die Kommando_Zeile übergeben.
für wget zumindest ein Alias mit der Option "-o" festlegen?
Diedrich Ehlerding
Mar 8, 2020, 2:37:45 PM3/8/20
to
Andreas Kohlbach meinte:
>> Mal ganz naive Idee (ich bin da nicht so ganz kundig): ließe sich nicht
>> für wget zumindest ein Alias mit der Option "-o" festlegen?
>
> -o legt *eine* Datei fest, anstatt mehrere Dateien in einem vorgegeben
> Verzeichnis anzulegen.
Wasd spricht gegen "wget -o wget-log.`date +%F-%T-%N`" (mit %N sollte der
Dateiname eindeutig werden)?
diedrich@diedrich:/tmp> wget -o wget-log.`date +%F-%T-%N`
http://unbekannter.server.invalid
diedrich@diedrich:/tmp> ls wget*
wget-log.2020-03-08-19:35:41-274278469
diedrich@diedrich:/tmp> wget -o wget-log.`date +%F-%T-%N`
http://unbekannter.server.invalid
diedrich@diedrich:/tmp> wget -o wget-log.`date +%F-%T-%N`
http://unbekannter.server.invalid
diedrich@diedrich:/tmp> ls wget*
wget-log.2020-03-08-19:35:41-274278469 wget-
log.2020-03-08-19:35:51-810318597
wget-log.2020-03-08-19:35:50-826233600
diedrich@diedrich:/tmp>
>> Mal ganz naive Idee (ich bin da nicht so ganz kundig): ließe sich nicht
>> für wget zumindest ein Alias mit der Option "-o" festlegen?
>
> Verzeichnis anzulegen.
Wasd spricht gegen "wget -o wget-log.`date +%F-%T-%N`" (mit %N sollte der
Dateiname eindeutig werden)?
diedrich@diedrich:/tmp> wget -o wget-log.`date +%F-%T-%N`
http://unbekannter.server.invalid
diedrich@diedrich:/tmp> ls wget*
wget-log.2020-03-08-19:35:41-274278469
diedrich@diedrich:/tmp> wget -o wget-log.`date +%F-%T-%N`
http://unbekannter.server.invalid
diedrich@diedrich:/tmp> wget -o wget-log.`date +%F-%T-%N`
http://unbekannter.server.invalid
diedrich@diedrich:/tmp> ls wget*
wget-log.2020-03-08-19:35:41-274278469 wget-
log.2020-03-08-19:35:51-810318597
wget-log.2020-03-08-19:35:50-826233600
diedrich@diedrich:/tmp>
Diedrich Ehlerding
Mar 8, 2020, 2:37:45 PM3/8/20
to
Andreas Kohlbach meinte:
>> Das hiesige wget schreibt nur dann, wenn es im Hintergrnnd läuft, nach
>> "wget-log" und wenn das schon existiert nach
>> "wget-log.<laufendenummer>". Wenn es im Vordergrund läuft, schreib es
>> nach stderr, wenn keine Option "-o logfile" angegeben ist. Und es
>> schreibt nicht nach $HOME, sondern nach $PWD.
>
> Hast Du nie Errors (Seite nicht erreichbar oder anderes)?
Wie kommst du auf diese Frage? Glaubst du nicht, was ich da ausprobiert
und besc hrieben habe; und wenn, wieso nicht? Ich habe testweise Fehler
provoziert provoziert (Server nicht erreichbar); die Meldung erschien nach
"wget http://unbekannter.server.invalid" auf stderr (und eben nicht in
wget-log*); nach "wget http://unbekannter.server.invalid &" erzeuigte er
bei mir ein wget-log und be Wiederholunmg ein get-log.1 Ich benutze wget
nur selten und wenn, dann normalerweise im Vordergrund.
Bei mir jedenfalls
- schreibt es Fehlermeldungen nur nach "wget-log*", wenn es im Hintergrund
läuft; ansonsten nach stderr .
- und erzeugt ggf. eben wget-log* nicht in $HOME/, sondern in $PWD/ ,
anders als du es beschrieben hast.
Schau hierhin. Erstmal in $HOME, dann in /tmp probier:
diedrich@diedrich:~> ls wget-log*
ls: Zugriff auf 'wget-log*' nicht möglich: Datei oder Verzeichnis nicht
gefunden
diedrich@diedrich:~> wget http://unbekannter.server.invalid
--2020-03-08 19:27:32-- http://unbekannter.server.invalid/
Auflösen des Hostnamens unbekannter.server.invalid
(unbekannter.server.invalid)… fehlgeschlagen: Der Name oder der Dienst ist
nicht bekannt.
wget: Host-Adresse »unbekannter.server.invalid« kann nicht aufgelöst
werden
diedrich@diedrich:~> wget http://unbekannter.server.invalid&
[1] 11554
diedrich@diedrich:~>
Ausgabe wird nach »wget-log« umgeleitet.
[1]+ Exit 4 wget http://unbekannter.server.invalid
diedrich@diedrich:~> wget http://unbekannter.server.invalid&
[1] 11562
diedrich@diedrich:~>
Ausgabe wird nach »wget-log.1« umgeleitet.
[1]+ Exit 4 wget http://unbekannter.server.invalid
diedrich@diedrich:~> ls wget-log*
wget-log wget-log.1
Und jetzt in einem anderen Directory:
diedrich@diedrich:~> cd /tmp
diedrich@diedrich:/tmp> ls wget-log*
ls: Zugriff auf 'wget-log*' nicht möglich: Datei oder Verzeichnis nicht
gefunden
diedrich@diedrich:/tmp> wget http://unbekannter.server.invalid&
[1] 11783
diedrich@diedrich:/tmp>
Ausgabe wird nach »wget-log« umgeleitet.
[1]+ Exit 4 wget http://unbekannter.server.invalid
diedrich@diedrich:/tmp> wget http://unbekannter.server.invalid&
[1] 11788
diedrich@diedrich:/tmp>
Ausgabe wird nach »wget-log.1« umgeleitet.
[1]+ Exit 4 wget http://unbekannter.server.invalid
diedrich@diedrich:/tmp> ls wget-log*
wget-log wget-log.1
diedrich@diedrich:/tmp>
>> Das hiesige wget schreibt nur dann, wenn es im Hintergrnnd läuft, nach
>> "wget-log" und wenn das schon existiert nach
>> "wget-log.<laufendenummer>". Wenn es im Vordergrund läuft, schreib es
>> nach stderr, wenn keine Option "-o logfile" angegeben ist. Und es
>> schreibt nicht nach $HOME, sondern nach $PWD.
>
Wie kommst du auf diese Frage? Glaubst du nicht, was ich da ausprobiert
und besc hrieben habe; und wenn, wieso nicht? Ich habe testweise Fehler
provoziert provoziert (Server nicht erreichbar); die Meldung erschien nach
"wget http://unbekannter.server.invalid" auf stderr (und eben nicht in
wget-log*); nach "wget http://unbekannter.server.invalid &" erzeuigte er
bei mir ein wget-log und be Wiederholunmg ein get-log.1 Ich benutze wget
nur selten und wenn, dann normalerweise im Vordergrund.
Bei mir jedenfalls
- schreibt es Fehlermeldungen nur nach "wget-log*", wenn es im Hintergrund
läuft; ansonsten nach stderr .
- und erzeugt ggf. eben wget-log* nicht in $HOME/, sondern in $PWD/ ,
anders als du es beschrieben hast.
Schau hierhin. Erstmal in $HOME, dann in /tmp probier:
diedrich@diedrich:~> ls wget-log*
ls: Zugriff auf 'wget-log*' nicht möglich: Datei oder Verzeichnis nicht
gefunden
diedrich@diedrich:~> wget http://unbekannter.server.invalid
--2020-03-08 19:27:32-- http://unbekannter.server.invalid/
Auflösen des Hostnamens unbekannter.server.invalid
(unbekannter.server.invalid)… fehlgeschlagen: Der Name oder der Dienst ist
nicht bekannt.
wget: Host-Adresse »unbekannter.server.invalid« kann nicht aufgelöst
werden
diedrich@diedrich:~> wget http://unbekannter.server.invalid&
[1] 11554
diedrich@diedrich:~>
Ausgabe wird nach »wget-log« umgeleitet.
[1]+ Exit 4 wget http://unbekannter.server.invalid
diedrich@diedrich:~> wget http://unbekannter.server.invalid&
[1] 11562
diedrich@diedrich:~>
Ausgabe wird nach »wget-log.1« umgeleitet.
[1]+ Exit 4 wget http://unbekannter.server.invalid
diedrich@diedrich:~> ls wget-log*
wget-log wget-log.1
Und jetzt in einem anderen Directory:
diedrich@diedrich:~> cd /tmp
diedrich@diedrich:/tmp> ls wget-log*
ls: Zugriff auf 'wget-log*' nicht möglich: Datei oder Verzeichnis nicht
gefunden
diedrich@diedrich:/tmp> wget http://unbekannter.server.invalid&
[1] 11783
diedrich@diedrich:/tmp>
Ausgabe wird nach »wget-log« umgeleitet.
[1]+ Exit 4 wget http://unbekannter.server.invalid
diedrich@diedrich:/tmp> wget http://unbekannter.server.invalid&
[1] 11788
diedrich@diedrich:/tmp>
Ausgabe wird nach »wget-log.1« umgeleitet.
[1]+ Exit 4 wget http://unbekannter.server.invalid
diedrich@diedrich:/tmp> ls wget-log*
wget-log wget-log.1
diedrich@diedrich:/tmp>
Diedrich Ehlerding
Mar 9, 2020, 9:50:03 AM3/9/20
to
Andreas Kohlbach meinte:
>> Was spricht gegen "wget -o wget-log.`date +%F-%T-%N`" (mit %N sollte
>> der Dateiname eindeutig werden)?
>
> Es geht mir darum, kein "unnötigen" Angaben zu machen. Wollte, dass ich
> in der .wgetrc sage, in welches Verzeichnis er loggen soll. Was
> funktionieren soll, ist die Vorgabe *eines* Logfiles an beliebigem Ort,
> an das angehängt wird.
Ich fürchte, ich verstehe dein Problem nicht.
Wenn du einzelne Logfiles, eines für jeden Aufruf von wget, in einem
bestimmten Verzeichnis haben willst, dann machst du wie oben den
Dateinamen eindeutig und erzeugst für jeden wget-Aufruf ein eigenes
Logfile mit Datum, Uhrzeit und noch irgendwelchen Nanosekunden im Namen.
Diede Logfiles kannst du nbatürlich auch in ein beliebiges Verzeichnis
legen (... -o /di/rec/to/ry/wget-log.`date +%F-%T-%N` )
Wenn du alles in ein einziges Logfile schreiben lassen wisst (immer
hintendran), dann nutze "wget -a /di/rec/t/ry/sammel-LLogfile. Und wenn du
für jeden Tag ein eigenes Logfile haben möchtest, aber alle wgets eines
Tages im selben, und wenn alle diese Logfilkes in einem bestimmetn
Directtory liegen soollen, dann eben
" ... -o /di/rec/to/ry/wget-log.`date +%F`; das
Logfile wird dann beim ersten wget des Tages erzeugt und dann wird
hintendrangeschrieben.
Ja, das steht dann nicht im .wgetrc. So what?
>> Was spricht gegen "wget -o wget-log.`date +%F-%T-%N`" (mit %N sollte
>> der Dateiname eindeutig werden)?
>
> Es geht mir darum, kein "unnötigen" Angaben zu machen. Wollte, dass ich
> in der .wgetrc sage, in welches Verzeichnis er loggen soll. Was
> funktionieren soll, ist die Vorgabe *eines* Logfiles an beliebigem Ort,
> an das angehängt wird.
Ich fürchte, ich verstehe dein Problem nicht.
Wenn du einzelne Logfiles, eines für jeden Aufruf von wget, in einem
bestimmten Verzeichnis haben willst, dann machst du wie oben den
Dateinamen eindeutig und erzeugst für jeden wget-Aufruf ein eigenes
Logfile mit Datum, Uhrzeit und noch irgendwelchen Nanosekunden im Namen.
Diede Logfiles kannst du nbatürlich auch in ein beliebiges Verzeichnis
legen (... -o /di/rec/to/ry/wget-log.`date +%F-%T-%N` )
Wenn du alles in ein einziges Logfile schreiben lassen wisst (immer
hintendran), dann nutze "wget -a /di/rec/t/ry/sammel-LLogfile. Und wenn du
für jeden Tag ein eigenes Logfile haben möchtest, aber alle wgets eines
Tages im selben, und wenn alle diese Logfilkes in einem bestimmetn
Directtory liegen soollen, dann eben
" ... -o /di/rec/to/ry/wget-log.`date +%F`; das
Logfile wird dann beim ersten wget des Tages erzeugt und dann wird
hintendrangeschrieben.
Ja, das steht dann nicht im .wgetrc. So what?
Christian Garbs
Mar 9, 2020, 2:59:56 PM3/9/20
to
Mahlzeit!
Diedrich Ehlerding <diedrich....@t-online.de> wrote:
> Wenn du alles in ein einziges Logfile schreiben lassen wisst (immer
> hintendran), dann nutze "wget -a /di/rec/t/ry/sammel-LLogfile. Und wenn du
> für jeden Tag ein eigenes Logfile haben möchtest, aber alle wgets eines
> Tages im selben, und wenn alle diese Logfilkes in einem bestimmetn
> Directtory liegen soollen, dann eben
> " ... -o /di/rec/to/ry/wget-log.`date +%F`; das
-a, nicht -o :-)
> Logfile wird dann beim ersten wget des Tages erzeugt und dann wird
> hintendrangeschrieben.
Gruß
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Murphy's Laws of Combat:
9. Teamwork is essential, it gives them someone else to shoot at.
Diedrich Ehlerding <diedrich....@t-online.de> wrote:
> Wenn du alles in ein einziges Logfile schreiben lassen wisst (immer
> hintendran), dann nutze "wget -a /di/rec/t/ry/sammel-LLogfile. Und wenn du
> für jeden Tag ein eigenes Logfile haben möchtest, aber alle wgets eines
> Tages im selben, und wenn alle diese Logfilkes in einem bestimmetn
> Directtory liegen soollen, dann eben
> " ... -o /di/rec/to/ry/wget-log.`date +%F`; das
> Logfile wird dann beim ersten wget des Tages erzeugt und dann wird
> hintendrangeschrieben.
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Murphy's Laws of Combat:
9. Teamwork is essential, it gives them someone else to shoot at.
Helmut Waitzmann
Mar 9, 2020, 3:58:19 PM3/9/20
to
Diedrich Ehlerding <diedrich....@t-online.de>:
>Das hiesige wget schreibt nur dann, wenn es im Hintergrnnd läuft,
>nach "wget-log" und wenn das schon existiert nach
>"wget-log.<laufendenummer>".
Interessant. Als ich das letzte Mal im Handbuch nachgelesen habe,
war darin nicht vom Laufen im Hintergrund die Rede. Es stand nur
drin, dass Wget bei Empfang des HUP‐Signals die Ausgabe, wenn sie
zuvor nach stdout ging, auf die Datei wget-log umstellt.
Steht bei dir im Wget‐Handbuch etwas vom Laufen im Hintergrund?
>Das hiesige wget schreibt nur dann, wenn es im Hintergrnnd läuft,
>nach "wget-log" und wenn das schon existiert nach
>"wget-log.<laufendenummer>".
war darin nicht vom Laufen im Hintergrund die Rede. Es stand nur
drin, dass Wget bei Empfang des HUP‐Signals die Ausgabe, wenn sie
zuvor nach stdout ging, auf die Datei wget-log umstellt.
Steht bei dir im Wget‐Handbuch etwas vom Laufen im Hintergrund?
Diedrich Ehlerding
Mar 9, 2020, 4:12:07 PM3/9/20
to
Christian Garbs meinte:
> -a, nicht -o
Ups. Stimmt. Danke.
> -a, nicht -o
Ups. Stimmt. Danke.
Diedrich Ehlerding
Mar 9, 2020, 4:19:40 PM3/9/20
to
Helmut Waitzmann meinte:
>
> Steht bei dir im Wget‐Handbuch etwas vom Laufen im Hintergrund?
| --background
| Go to background immediately after startup. If no output
| file is specified via the -o, output is redirected to
| wget-log.
Es ist hier die Version aus opensuse 15.1; genauer:
diedrich@diedrich:~> rpm -qa | grep wget
wget-1.19.5-lp151.4.1.x86_64
diedrich@diedrich:~>
>
> Steht bei dir im Wget‐Handbuch etwas vom Laufen im Hintergrund?
| Go to background immediately after startup. If no output
| file is specified via the -o, output is redirected to
| wget-log.
Es ist hier die Version aus opensuse 15.1; genauer:
diedrich@diedrich:~> rpm -qa | grep wget
wget-1.19.5-lp151.4.1.x86_64
diedrich@diedrich:~>
Diedrich Ehlerding
Mar 10, 2020, 10:35:09 AM3/10/20
to
Andreas Kohlbach meinte:
>>>> Was spricht gegen "wget -o wget-log.`date +%F-%T-%N`" (mit %N sollte
>>>> der Dateiname eindeutig werden)?
[...]
>>>> Was spricht gegen "wget -o wget-log.`date +%F-%T-%N`" (mit %N sollte
>>>> der Dateiname eindeutig werden)?
>> Ich fürchte, ich verstehe dein Problem nicht.
>
> Er soll, ohne Angabe zusätzlicher Parameter, *mehrere* Log Dateien in
>
> einem Verzeichnis meiner Wahl (das soll /var/tmp/ sein, in dem Dateien,
> die älter als acht Tage sind, automatisch abgeräumt werden) schreiben.
[...]
> Dein durchaus funktionierender Vorschlag hat aber zusätzliche Parameter.
Der vorherige Vorschlag - vor dem wget ein lockeres "cd /var/tmp" -
konveniert dir ja anscheinend auch nicht. Funkionieren müsste der aber
auch (und zwar ohne Parameter); allerdings ist da das Abräumen
prolematisch - möglicherweise fängt wget da mit dem Zählen von vorn wieder
an, wenn wget-log.1 bis wget-log.10 weggeräumt sind, wgetlog.11 abert noch
existiert. Probiere ich jetzt aber nicht aus.
Je nun, du bestätigst also, dass obiger Vorschlag den Effekt hat, den du
erreichen willst; du versteifst dich aber daraus, dass das doch in in die
.wgetrc gehört!!!1elf. Ich fürchte, da wird dir nichts anderes
übrigbleiben als den wget-Quelltext zu Rate zu ziehen und entsprechend zu
erweitern. Vielleicht verbreitet sich deine Version ja dann (auch wenn
bisher anscheinend niemand den Bedarf gesehen hat).
Christian Garbs
Mar 10, 2020, 2:27:34 PM3/10/20
to
Mahlzeit!
Andreas Kohlbach <a...@spamfence.net> wrote:
Für bash:
wget() {
$(which wget) -o /tmp/wget-log.$(date +%F-%T-%N) "@*"
}
Für andere Shells wohl ähnlich :)
In der Luxusversion schleifst Du noch einmal über alle Parameter und
guckst, ob von außen ein -o mitgegeben wurde, dann setzt Du selber
kein -o.
Und wenn Dein Rechner zu schnell für den Timestamp ist, kannst Du noch
die Prozess-ID mit in den Dateinamen aufnehmen (ggf. statt %N).
"Igitt, nicht schon wieder Käsemauken!"
"Mund halten und aufessen! Die enthalten viel gutes Vitamin Zeh!"
Andreas Kohlbach <a...@spamfence.net> wrote:
> On Mon, 09 Mar 2020 14:17:30 +0100, Diedrich Ehlerding wrote:
>> Wenn du einzelne Logfiles, eines für jeden Aufruf von wget, in einem
>> bestimmten Verzeichnis haben willst, dann machst du wie oben den
>> Dateinamen eindeutig und erzeugst für jeden wget-Aufruf ein eigenes
>> Logfile mit Datum, Uhrzeit und noch irgendwelchen Nanosekunden im Namen.
>> Diede Logfiles kannst du nbatürlich auch in ein beliebiges Verzeichnis
>> legen (... -o /di/rec/to/ry/wget-log.`date +%F-%T-%N` )
>
>> Wenn du einzelne Logfiles, eines für jeden Aufruf von wget, in einem
>> bestimmten Verzeichnis haben willst, dann machst du wie oben den
>> Dateinamen eindeutig und erzeugst für jeden wget-Aufruf ein eigenes
>> Logfile mit Datum, Uhrzeit und noch irgendwelchen Nanosekunden im Namen.
>> Diede Logfiles kannst du nbatürlich auch in ein beliebiges Verzeichnis
>> legen (... -o /di/rec/to/ry/wget-log.`date +%F-%T-%N` )
>
> Dein durchaus funktionierender Vorschlag hat aber zusätzliche Parameter.
Machst Du eine Shellfunktion draus und packst sie ins .profile oder so:
Für bash:
wget() {
$(which wget) -o /tmp/wget-log.$(date +%F-%T-%N) "@*"
}
Für andere Shells wohl ähnlich :)
In der Luxusversion schleifst Du noch einmal über alle Parameter und
guckst, ob von außen ein -o mitgegeben wurde, dann setzt Du selber
kein -o.
Und wenn Dein Rechner zu schnell für den Timestamp ist, kannst Du noch
die Prozess-ID mit in den Dateinamen aufnehmen (ggf. statt %N).
"Igitt, nicht schon wieder Käsemauken!"
"Mund halten und aufessen! Die enthalten viel gutes Vitamin Zeh!"
Helmut Waitzmann
Mar 10, 2020, 5:41:23 PM3/10/20
to
Diedrich Ehlerding <diedrich....@t-online.de>:
Hier hat mir der Begriff «Hintergrund» einen Streich gespielt:
«Hintergrund» im Bezug auf Prozesse beziehe ich in der POSIX‐Welt
immer auf job control. Ein Prozess befindet sich genau dann im
Hintergrund, wenn er zu einem anderen job group gehört als das,
das im Augenblick in seinem controlling terminal als foreground
job group eingestellt ist. Unter anderem das Einstellen ist das,
was das POSIX‐Shell mit den Kommandos «fg» und «bg» macht.
Das, was im Wget‐Handbuch als «background» bezeichnet wird, würde
ich als «orphaned» oder verwaist bezeichnen. Ein verwaister
Prozess ist einer, dessen Vater bereits gestorben ist. (Deshalb
wird der verwaiste Prozess vom Prozess mit der Nummer 1
adoptiert.) Dass das Erzeugen eines Kind‐Prozesses und
Sterbenlassen seines Vaters im Funktionsumfang von Wget enthalten
ist, habe ich in meinem Kopf mit dem Kommentar «unnötig» versehen
und vergessen, denn ähnliches kann man auch mit dem Shell‐Kommando
( wget -o wget-log & )
erreichen.
Darüber hinaus: Was bedeutet im zitierten Handbuchtext
«immediately after startup»? Gibt es also Meldungen, die während
des startups auftreten können und deshalb noch nicht in die Datei
wget-log sondern noch nach standard error geschrieben werden? Wie
sieht es mit dem exit status aus?
Auch wegen dieser Unklarheiten habe ich die Funktionalität als
nicht genau spezifiziert eingeschätzt und als unbrauchbar
verworfen.
>Helmut Waitzmann meinte:
>> Steht bei dir im Wget‐Handbuch etwas vom Laufen im Hintergrund?
>>
>
>| --background
>| Go to background immediately after startup. If no output
>| file is specified via the -o, output is redirected to
>| wget-log.
>
Wie heißt es so schön? I stand corrected.
>> Steht bei dir im Wget‐Handbuch etwas vom Laufen im Hintergrund?
>>
>
>| --background
>| Go to background immediately after startup. If no output
>| file is specified via the -o, output is redirected to
>| wget-log.
>
Hier hat mir der Begriff «Hintergrund» einen Streich gespielt:
«Hintergrund» im Bezug auf Prozesse beziehe ich in der POSIX‐Welt
immer auf job control. Ein Prozess befindet sich genau dann im
Hintergrund, wenn er zu einem anderen job group gehört als das,
das im Augenblick in seinem controlling terminal als foreground
job group eingestellt ist. Unter anderem das Einstellen ist das,
was das POSIX‐Shell mit den Kommandos «fg» und «bg» macht.
Das, was im Wget‐Handbuch als «background» bezeichnet wird, würde
ich als «orphaned» oder verwaist bezeichnen. Ein verwaister
Prozess ist einer, dessen Vater bereits gestorben ist. (Deshalb
wird der verwaiste Prozess vom Prozess mit der Nummer 1
adoptiert.) Dass das Erzeugen eines Kind‐Prozesses und
Sterbenlassen seines Vaters im Funktionsumfang von Wget enthalten
ist, habe ich in meinem Kopf mit dem Kommentar «unnötig» versehen
und vergessen, denn ähnliches kann man auch mit dem Shell‐Kommando
( wget -o wget-log & )
erreichen.
Darüber hinaus: Was bedeutet im zitierten Handbuchtext
«immediately after startup»? Gibt es also Meldungen, die während
des startups auftreten können und deshalb noch nicht in die Datei
wget-log sondern noch nach standard error geschrieben werden? Wie
sieht es mit dem exit status aus?
Auch wegen dieser Unklarheiten habe ich die Funktionalität als
nicht genau spezifiziert eingeschätzt und als unbrauchbar
verworfen.
Helmut Waitzmann
Mar 10, 2020, 6:20:43 PM3/10/20
to
Christian Garbs <mi...@cgarbs.de>:
Auf «which» zurückzugreifen, scheint nicht auszusterben, obwohl es
weder im POSIX‐Standard noch im bash enthalten ist. Darüber
hinaus scheitert «$(…)» bei «lustigen» Dateinamen, und es
verschweigt gewisse Fehlerfälle (probiere mal das Kommando
$(which Blabla) Gefasel
aus).
Statt dessen sind sowohl
wget()
{
command -- wget -o /tmp/wget-log.$(date +%F-%T-%N) "$@"
}
(«command» schließt Funktionsaufrufe aus) als auch
wget()
(
exec wget -o /tmp/wget-log.$(date +%F-%T-%N) "$@"
)
(«exec» zieht nur externe Programme in Betracht und entspricht
deshalb dem «which» am besten) robust und vom POSIX‐Standard
gedeckt.
>Andreas Kohlbach <a...@spamfence.net> wrote:
>> On Mon, 09 Mar 2020 14:17:30 +0100, Diedrich Ehlerding wrote:
>
>>> Wenn du einzelne Logfiles, eines für jeden Aufruf von wget, in
>>> einem bestimmten Verzeichnis haben willst, dann machst du wie
>>> oben den Dateinamen eindeutig und erzeugst für jeden
>>> wget-Aufruf ein eigenes Logfile mit Datum, Uhrzeit und noch
>>> irgendwelchen Nanosekunden im Namen. Diede Logfiles kannst du
>>> nbatürlich auch in ein beliebiges Verzeichnis legen
>>> (... -o /di/rec/to/ry/wget-log.`date +%F-%T-%N` )
>>
>> Dein durchaus funktionierender Vorschlag hat aber zusätzliche
>> Parameter.
>
>Machst Du eine Shellfunktion draus und packst sie ins .profile
>oder so:
>
>Für bash:
>
>
>wget() {
> $(which wget) -o /tmp/wget-log.$(date +%F-%T-%N) "@*"
>}
Was ist «"@*"»? Ich würde wärmstens «"$@"» empfehlen.
>> On Mon, 09 Mar 2020 14:17:30 +0100, Diedrich Ehlerding wrote:
>
>>> Wenn du einzelne Logfiles, eines für jeden Aufruf von wget, in
>>> einem bestimmten Verzeichnis haben willst, dann machst du wie
>>> oben den Dateinamen eindeutig und erzeugst für jeden
>>> wget-Aufruf ein eigenes Logfile mit Datum, Uhrzeit und noch
>>> irgendwelchen Nanosekunden im Namen. Diede Logfiles kannst du
>>> nbatürlich auch in ein beliebiges Verzeichnis legen
>>> (... -o /di/rec/to/ry/wget-log.`date +%F-%T-%N` )
>>
>> Dein durchaus funktionierender Vorschlag hat aber zusätzliche
>> Parameter.
>
>Machst Du eine Shellfunktion draus und packst sie ins .profile
>oder so:
>
>Für bash:
>
>
>wget() {
> $(which wget) -o /tmp/wget-log.$(date +%F-%T-%N) "@*"
>}
Auf «which» zurückzugreifen, scheint nicht auszusterben, obwohl es
weder im POSIX‐Standard noch im bash enthalten ist. Darüber
hinaus scheitert «$(…)» bei «lustigen» Dateinamen, und es
verschweigt gewisse Fehlerfälle (probiere mal das Kommando
$(which Blabla) Gefasel
aus).
Statt dessen sind sowohl
wget()
{
command -- wget -o /tmp/wget-log.$(date +%F-%T-%N) "$@"
}
(«command» schließt Funktionsaufrufe aus) als auch
wget()
(
exec wget -o /tmp/wget-log.$(date +%F-%T-%N) "$@"
)
(«exec» zieht nur externe Programme in Betracht und entspricht
deshalb dem «which» am besten) robust und vom POSIX‐Standard
gedeckt.
Juergen Ilse
Mar 10, 2020, 10:45:34 PM3/10/20
to
Hallo,
Helmut Waitzmann <nn.th...@xoxy.net> wrote:
> Statt dessen sind sowohl
>
>
> wget()
> {
> command -- wget -o /tmp/wget-log.$(date +%F-%T-%N) "$@"
> }
>
> («command» schließt Funktionsaufrufe aus) als auch
>
>
> wget()
> (
> exec wget -o /tmp/wget-log.$(date +%F-%T-%N) "$@"
> )
In solchen Faellen sollte man sich angewoehnen, den Aufruf des executables
in der Funktionsdefinition mit vollem Pfad zu machen. Die Verwendung von
"commabd" reduziert zwar das Risiko, unerwuenschtes auszufuehren, aber ist
dasshellbuiltin "command" nicht ein "bashism"? Falls ja, sollte man es nur
verwenden, wenn absolut sichergestellt werden kann, dass die Funktionsde-
finition niemals in einer anderen shell verwendet wird ...
Auch waere eine Aenderung der Semantik einer shellfunktion durcvh Aenderung
des Suchpfades eher *sehr* ueberraschend und IMHO daher besser zu vermeiden.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Helmut Waitzmann <nn.th...@xoxy.net> wrote:
> Statt dessen sind sowohl
>
>
> wget()
> {
> command -- wget -o /tmp/wget-log.$(date +%F-%T-%N) "$@"
> }
>
> («command» schließt Funktionsaufrufe aus) als auch
>
>
> wget()
> (
> exec wget -o /tmp/wget-log.$(date +%F-%T-%N) "$@"
> )
in der Funktionsdefinition mit vollem Pfad zu machen. Die Verwendung von
"commabd" reduziert zwar das Risiko, unerwuenschtes auszufuehren, aber ist
dasshellbuiltin "command" nicht ein "bashism"? Falls ja, sollte man es nur
verwenden, wenn absolut sichergestellt werden kann, dass die Funktionsde-
finition niemals in einer anderen shell verwendet wird ...
Auch waere eine Aenderung der Semantik einer shellfunktion durcvh Aenderung
des Suchpfades eher *sehr* ueberraschend und IMHO daher besser zu vermeiden.
Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
Helmut Waitzmann
Mar 11, 2020, 10:13:33 AM3/11/20
to
Juergen Ilse <ne...@usenet-verwaltung.de>:
>Die Verwendung von "commabd" reduziert zwar das Risiko,
>unerwuenschtes auszufuehren, aber ist dasshellbuiltin "command"
>nicht ein "bashism"?
Du kannst gerne selbst im POSIX‐Standard nachlesen, wie dort
«command» und «exec» festgelegt sind (wenn du meinem von dir
nicht mitzitierten Satzende keinen Glauben schenken willst).
>Auch waere eine Aenderung der Semantik einer shellfunktion durcvh
>Aenderung des Suchpfades eher *sehr* ueberraschend und IMHO daher
>besser zu vermeiden.
Nicht in diesem Fall. Es geht hier um Vorschläge, wie Andreas den
Parameter «-o» beim Aufruf von wget vermeiden kann. Sein
Wget‐Aufruf ist vom Wert der Umgebungsvariablen «PATH» abhängig.
Deshalb muss es die Shell‐Funktion, um dazu kompatibel zu sein,
ebenso tun.
Keiner von uns weiß, ob Andreas in «/usr/local/bin/» oder gar in
«"$HOME"/bin/» eine Extra‐Fassung von wget stehen hat – und
wir müssen es auch nicht wissen, weil sich sowohl «command» als
auch «exec» selber darum kümmern.
>Helmut Waitzmann <nn.th...@xoxy.net> wrote:
>> Statt dessen sind sowohl
>>
>>
>> wget()
>> {
>> command -- wget -o /tmp/wget-log.$(date +%F-%T-%N) "$@"
>> }
>>
>> («command» schließt Funktionsaufrufe aus) als auch
>>
>>
>> wget()
>> (
>> exec wget -o /tmp/wget-log.$(date +%F-%T-%N) "$@"
>> )
>
>In solchen Faellen sollte man sich angewoehnen, den Aufruf des
>executables in der Funktionsdefinition mit vollem Pfad zu machen.
Nicht in diesem Fall.
>> Statt dessen sind sowohl
>>
>>
>> wget()
>> {
>> command -- wget -o /tmp/wget-log.$(date +%F-%T-%N) "$@"
>> }
>>
>> («command» schließt Funktionsaufrufe aus) als auch
>>
>>
>> wget()
>> (
>> exec wget -o /tmp/wget-log.$(date +%F-%T-%N) "$@"
>> )
>
>In solchen Faellen sollte man sich angewoehnen, den Aufruf des
>executables in der Funktionsdefinition mit vollem Pfad zu machen.
>Die Verwendung von "commabd" reduziert zwar das Risiko,
>unerwuenschtes auszufuehren, aber ist dasshellbuiltin "command"
>nicht ein "bashism"?
«command» und «exec» festgelegt sind (wenn du meinem von dir
nicht mitzitierten Satzende keinen Glauben schenken willst).
>Auch waere eine Aenderung der Semantik einer shellfunktion durcvh
>Aenderung des Suchpfades eher *sehr* ueberraschend und IMHO daher
>besser zu vermeiden.
Parameter «-o» beim Aufruf von wget vermeiden kann. Sein
Wget‐Aufruf ist vom Wert der Umgebungsvariablen «PATH» abhängig.
Deshalb muss es die Shell‐Funktion, um dazu kompatibel zu sein,
ebenso tun.
Keiner von uns weiß, ob Andreas in «/usr/local/bin/» oder gar in
«"$HOME"/bin/» eine Extra‐Fassung von wget stehen hat – und
wir müssen es auch nicht wissen, weil sich sowohl «command» als
auch «exec» selber darum kümmern.
Christian Garbs
Mar 11, 2020, 1:50:24 PM3/11/20
to
Mahlzeit!
Helmut Waitzmann <nn.th...@xoxy.net> wrote:
> Christian Garbs <mi...@cgarbs.de>:
>>wget() {
>> $(which wget) -o /tmp/wget-log.$(date +%F-%T-%N) "@*"
>>}
> Was ist «"@*"»?
Ein Fipptehler vom Zurückeditieren, weil ich testweise einmal aus dem
"@*" ein "$*" gemacht habe, um zu sehen, wie das kaputtgeht.
> Auf «which» zurückzugreifen, scheint nicht auszusterben,
Toll fand ich es auch nicht, aber den festen Pfad wollte ich nicht nutzen.
> command -- wget -o /tmp/wget-log.$(date +%F-%T-%N) "$@"
Danke
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Linux oder Windows? Das ist eine Entscheidung zwischen GPL und GPF.
Helmut Waitzmann <nn.th...@xoxy.net> wrote:
> Christian Garbs <mi...@cgarbs.de>:
>>wget() {
>> $(which wget) -o /tmp/wget-log.$(date +%F-%T-%N) "@*"
>>}
> Was ist «"@*"»?
"@*" ein "$*" gemacht habe, um zu sehen, wie das kaputtgeht.
> Auf «which» zurückzugreifen, scheint nicht auszusterben,
> command -- wget -o /tmp/wget-log.$(date +%F-%T-%N) "$@"
> exec wget -o /tmp/wget-log.$(date +%F-%T-%N) "$@"
Die beiden Varianten muss ich mir merken!
Danke
Christian
--
....Christian.Garbs....................................https://www.cgarbs.de
Linux oder Windows? Das ist eine Entscheidung zwischen GPL und GPF.
0 new messages