Re: Bash Einzeiler Zeit+Datum letzter Eintrag dmesg
Hallo,
Am Sat, 20 Aug 2011, Rico Koerner schrieb:
>Am 20.08.2011 07:37, schrieb David Haller:
>> Am Mon, 15 Aug 2011, Rico Koerner schrieb:
>>> Am 15.08.2011 08:39, schrieb David Haller:
>>>> Am Sun, 14 Aug 2011, Rico Koerner schrieb:
>
>>>> dmesg ist also schon der richtige Ansatz.
>>>
>>> Das hab ich ja nicht verworfen.
>>>
>>>>> Dort steht die Zeit ja schon am Anfang der Zeile. Somit wird immer die
>>>>> korrekte Zeit ausgegeben.
>>>
>>> Nein, eben nicht. Die Abweichung wurde ja nun schon mehrfach
>>> festgestellt. Nur deshalb hab ich den Weg verfolgt.
>>
>> Wie gesagt, ich denke das ist ein Sonderfall. Leider hat Frank keine
>> "Rohdaten" (uptime, timestamp in dmesg/syslog) mit denen dann
>> weitergerechnet wird geliefert.
>
>Ein Sonderfall ist es eben nicht, Abweichungen treten auf allen
>Maschinen auf. Die Höhe der Abweichung (pro Zeiteinheit) ist auf jeder
>Maschine anders und multipliziert sich entsprechend mit der Uptime.
>Auffällig wirds nur, wenn das Datum in der Zukunft liegt oder wenn man
>genau hinschaut.
Der Einzeiler kann eben nur mit den Daten rechen, die man ihm
vorgibt. Auf die "Richtigkeit" der Daten hat der Befehl keinen Einfluß.
>> Wobei man hier ergänzen sollte: 'cut -c' oder andere zeichenabhängiger
>> Kram sind immer "fragil". Musterbasierte wie cut -fN -dX, die awk-
>> oder sed-Variante sind robuster.
>
>An der Stelle läßt sich auch cut -f1,2,3 -d' ' einsetzen, wenn dir das
>besser gefällt.
Aber mit sed kann man an Regexen splitten und awk kann Regexe als
Feldtrenner.
>Das fiel mir aber in dem Moment grad nicht ein.
>Das ist dann wohl eher Geschmackssache, ob man cut, sed oder awk
>einsetzt. Lieber wäre mir an der Stelle eine Bash-Substitution gewesen.
>Das wäre die effizientere Art, da dann der zusätzliche Prozeß wegfallen
>würde.
Wird dann aber eher aufwendig.
>Nicht kritischer als die Musterbasierte und fallabhängig zu betrachten,
>Syslog schreibt nun mal das Datum in einer konstanten Länge da rein.
>Sollte sich dieses ändern, ändert sich mit genauso hoher
>Wahrscheinlichkeit auch das Muster.
Die Zeitstempel in dmesg gibt's noch gar nicht so lange ...
>>>> Mantra: Prozesse starten, Disk- und Console-I/O ist lahm!
>>> Dann spar dir doch auch den seq-Aufruf, das kann die bash auch allein. ;-)
>>>
>>> ++ for i in {1..1000};
>>
>> Ach, alte Gewohnheit, hab 10 Jahre mit bash-2.x programmiert ... Und
>>
>> 1. es ist genau 1 Aufruf pro Durchlauf (und nicht _in_ der Schleife)
>
>Das trifft übrigens auch auf das ürsprüngliche Konstrukt zu. Ich wollte
>schon am Anfang mal einwerfen, daß die ganze Millisekundenschinderei
>hier vollkommen nebensächlich ist, da das real nur ein einzelner Aufruf
>sein wird. Wenn du damit anfängst, sei auch bei dir konsequent.
>Also sei fair bei dem Vergleich und rechne das genauso hoch für dein seq.
Die Schleife ist doch nur dazu da, erkennbare Unterschiede
aufzuzeigen. Und die Schleife gehört eben *nicht* zu dem was gemessen
werden soll. Der Op hat nicht gesagt, wie er das ganze einsetzen
will.
>Um mit gleichen Maßstäben zu messen:
>~$ time { for i in {1..1000}; do for x in `seq 1 1000`; do :; done; done
>> /dev/null; }
>
>real 0m10.996s
>user 0m9.581s
>sys 0m1.892s
>~$ time { for i in {1..1000}; do for x in {1..1000}; do :; done; done >
>/dev/null; }
>
>real 0m6.853s
>user 0m6.844s
>sys 0m0.000s
Ja eben. Und jetzt mach mal:
~$ time { for i in `seq 1 1000`; do \
for x in `seq 1 1000`; do :; done; done > /dev/null; }
~$ time { for i in `seq 1 1000`; do \
for x in {1..1000}; do :; done; done >/dev/null; }
Du wirst jew. praktisch die gleichen Zahlen wie oben bekommen. Es ist
nicht relevant, was in der äußeren Schleife verwendet wird, die Zeit
für das _eine_ seq oder das ein 'in {1..1000}' ist praktisch konstant
wenn du vorher einmal schon seq aufrufst. Ansonsten schlägt evtl. die
Zeit für's laden von seq von der Platte zu (denk dir seq liegt auf nem
nfs-share das per 3600er Modem angebunden ist als Extremfall, da würde
das erste seq schon ein bissl dauern, alle weiteren aus dem lokalen
Plattencache aber nicht).
>> Noch ein Mantra/ne Faustregel: wer in einer Pipe mehr als genau ein
>> 'cut', 'sed', 'awk' oder 'perl' (python) verwendet, der macht was
>> falsch. Mit dem jew. nächstgenannten Tool kann man eigentlich immer
>> das geforderte effektiver erledigen.
>
>Naja, für einen schnellen Hack ist es manchmal besser ein paar
>Millisekunden CPU-Zeit zu verbraten, als einen Tag über die optimale
>Lösung zu grübeln.
Ich mußte nicht grübeln. Das ist es ja gerade, ich muß mir keinen Kopp
um Effizienz machen, ich hab Erfahrungen die ich ab und an teste. Und
den awk hab ich vermutlich schneller geschrieben als ich die
Ursprungs-Variante geschrieben hätte (allein das Zeichenzählen ;)
>Auch ein Mantra: So gut wie nötig, nicht so gut wie möglich.
Ja. Wie gesagt: meine "Faustregeln" oder Mantras beruhen auf
Erfahrungen, ich überlege kurz, wie ich das Problem grundsätzlich
lösen könnte, schau mir an was ich dazu machen müßte (Zeit aus dmesg
und /proc/uptime holen), und was damit rechnen. Meist ist es dann für
mich ein "Nobrainer" zu entscheiden, was ich verwende.
Klar, direkt auf der Kommandozeile, beim testen oder bei nem konkreten
Problem, da kommt auch bei mir uneffektives vor, aber sowas schreib
ich nicht (so) in ein Script.
>> $ seq 10 | headntail -2 | xargs
>> 1 2 9 10
>
>Wozu braucht man das?
Wann immer du eine head + tail Kombination haben willst. Ist auch noch
flexibler:
$ seq 20 | headntail -s 10:4 -e 5:2 | xargs
7 8 9 10 16 17
$ seq 20 | headntail -s 15:5 | xargs
11 12 13 14 15
$ seq 20 | headntail -1 -s 15:5 | xargs ### == -e 1[:1] -s 15:5
11 12 13 14 15 20
$ seq 20 | headntail -1 -e 15:5 | xargs ### == -s 1[:1] -e 15:5
1 6 7 8 9 10
$ ps ax | headntail -s 1 -e 2
PID TTY STAT TIME COMMAND
26267 pts/8 R+ 0:00 ps ax
26311 pts/8 S+ 0:00 /usr/bin/gawk -f /home/dh/bin/headntail -s 1 -e 2
z.B. für sowas, wo man z.B. gern die Spaltenüberschriften hätte bei
nem "tail" mit dabei hätte ;)
Achso, 'headntail -2' ist äquivalent zu 'headntail -s 2:2 -e 2:2'.
$ headntail -h
USAGE: headntail [-s N[:LEN]] [-e N[:LEN]] [-N[:LEN]]
Da sollte ich das letzte noch zu '-n N[:LEN]' ergänzen ;) Im Script
selbst steht noch mehr "Usage".
>> War auf jedenfall eine sehr lehrreiche awk-Programmierübung für
>> mich[3] und ist sogar teils sinnvoll kommentiert ;)
>
>Aha, also ähnlich dem hiesigen Problem, einfach nur aus Spaß am
>Programmieren.
Nein, ich hatte schon einen konkreten Bedarf und wollte den eben mal
mit awk machen statt immer nur in perl oder ineffizient mit der bash.
Und, wie sich herausstellte war's eine sehr lehrreiche Aufgaben-
stellung :)
>> -dnh, der die Tage endlich mal das ISO von seiner ersten Linux-CD
>> gezogen hat: Debian-1.3.1_chip_ed.iso vom Dec. 1997 aka "bo" :)
>> Auch deswegen lunger ich hier auf der ML rum, obwohl ich aktuell
>> kein Debian im Einsatz habe ...
>
>Auch etwa zu der Zeit gestartet, aber zuerst Slackware probiert, schnell
>wieder weggeworfen. Danach Suse einige Jahre genutzt und erst mit Debian
>so richtig glücklich geworden.
Ich hatte mein Debian schnell kaputtgespielt (hab aber auch wirklich
sehr viel ausprobiert ;) Und dann 2 SUSEn. Dann über Jahre ne ex-SuSE.
Inzwischen wieder eine. Und parallel ein Gentoo. Debian hab ich aber
immer verfolgt und immer wieder mal getestet. Slackware müßte ich mal
gucken. Aber ich bin faul. Ubuntu mal ne Live-CD (c't Beilagen z.B.)
angeguckt bzw. auf Fremdrechnern verwendet. Kommt mir nicht auf die
Kisten. Mich nervt ja sogar Gentoo mit Voreinstellungen in gewissen
ebuilds.
>> [0] und mein Hauptrechner davor war seit 2000 ein 500 MHz Athlon, der
>> langsamste den's je gab ;) Allerdings hab ich seit ~4 Jahren nen
>> Zweitrechner mit nem Athlon 64 X2 3800+EE (2x2.0 GHz), der
>> inzwischen nur noch Fileserver macht (und dessen NT zu sterben
>> scheint *grumpf*).
>
>Zeit für einen Umstieg. Wenn du die Stromkosten berücksichtigst ist neue
>Hardware billiger.
Äh, das _war_ für 10 Jahre mein Hauptrechner (mit o.g. SuSE das '99
installiert wurde und zum ex-SUSE mutierte ;) Was mein aktueller
Hauptrechner ist stand vor dem [0] im eigentlichen Text. Lies meine
vorige Mail nochmal ;)
>> [3] bei Interesse (->per PM kundtun bitte) mail ich das gern per PM
>> oder lad's ggfs. auf meine Webseite.
>
>Wo bleibt der Opensourcegedanke? Legs doch gleich auf die Webseite und
>gib der Community etwas zurück. Vielleicht interessieren sich mehr Leute
>dafür, als du denkst.
Äh, bisher hat das halt noch keiner angeschaut/getestet, wenn ich
wenigstens mal eine Rückmeldung habe vielleicht. Also wenn du dir das
anschauen / testen willst, melde dich (andere auch), bei genug
Interesse pack ich's auf meine Webseite.
-dnh
--
I'm extremely disappointed. I send you out for exciting, new designer drugs,
you come back with tomato sauce. -- Dr. House
Reply to: