Timestamp von ntp Server abfragen und in Unixtime ausgeben?

[meinereinerseiner]

Hallo,

hat jemand eine idee, wie ich mit einem shell script einen ntp server Abfrage und das ergebnis als Unixtime (also Sekunden seit 1970) bekomme?

Mit "ntpdate -q server" habe ich zwar die Zeit, allerdings im falschen Format und ohne Jahr.

Bin für alles offen
der tom

[jan61]

Moin,

frag date:
jack:~ # date +%s -d "`ntpdate -q 0.de.pool.ntp.org | \
> awk -v j=\`date +%Y\` ' NR == 2 { print $1, $2, j, $3 } '`"
1213899649Jan

[meinereinerseiner]

Hi,

hey das klappt bestens - danke.

der neugier wegen: wie um alles in der welt kommt man auf so eine lösung? :)


der tom

[peschmae]

Dat weiss man halt einfach ;)

Das ist sowieso das Problem in der Shell - man muss einfach alle Tools gut kennen (die natürlich komplett inkonsistent sind und alle so ihre eigenen speziellen merkwürdigen aber plötzlich nützlichen Features haben...), erst dann wird man effizient.

MfG Peschmä

[meinereinerseiner]

plötzlich nützlichen Features

ja, wie recht du doch hast!

der tom

[jan61]

Moin,


...der neugier wegen: wie um alles in der welt kommt man auf so eine lösung? :)

Keine Ahnung :rolleyes:

Ich kann nur Vermutungen anstellen :o - ein paar Jahre Erfahrung mit Unixen und Shells; Programmieren (in diversen Sprachen/Tools, damit bleibt man gelenkig ;-) - ist nebenbei auch mein Job; sehr viel Ausprobieren (ich bemühe mich, alle von mir vorgeschlagenen Lösungswege auf meinem "jack" oder notfalls einem anderen Rechner mal durchzuspielen) und sicher unheimlich viel Neugierde: Wenn ich eine Frage interessant finde (kommt komischerweise oft vor), dann probiere ich eben rum, ob ich eine Lösung finde.

Gerade durch die Beschäftigung mit Fragen wie dieser hier lerne ich ja selbst sehr viel - und dadurch habe ich eben oft Methoden parat, weil ich das Thema in irgendeiner Form irgendwann schon mal durchgespielt habe.

Meine Antworten kommen in der Regel nicht einfach so daher, meist blitzt irgendwo in /dev/brain eine schwache Erinnerung auf ("da war doch mal was") und dann gehts ab auf die Kommandozeile (meine Definition eines GUI: 4 virtuelle Desktops mit je 6 offenen Terminal-Sessions), um zu probieren und Manual-Pages zu lesen.

So ein Online-Forum verführt manchmal zu der Meinung, man schüttele die Lösungen einfach so aus der Hand - das ist oft nicht so. Ich habe nur einige Werkzeuge wie die Unix-Shells halbwegs bedienen gelernt und dadurch habe ich mittlerweile eine Ahnung davon, was man alles damit machen kann. Man muss nur bereit sein, schon mal eine Stunde beim Basteln zu verbraten (wie bei dem komplizierten sed neulich) - aber ich finde, das lohnt sich für mich genauso wie für den Fragenden, weil ich dadurch Sachen probiere, auf die ich von selbst nicht mal im Traum gekommen wäre ;-)

Dies hier ist für mich also sowas wie eine kostenlose Weiterbildung :rolleyes:

Jan

[jan61]

Moin,


...die natürlich komplett inkonsistent sind...

was meinst Du denn mit "inkonsistent"?

Jan

[jan61]

Moin,

noch ne Bemerkung:


Das ist sowieso das Problem in der Shell - man muss einfach alle Tools gut kennen...

Nein, genau das muss man nicht. Eigentlich braucht man nur 2 Kommandos zu kennen: apropos und man. Danach braucht man nur noch lesen zu können - idealerweise auch in Englisch.

Glaubst Du etwa, dass ich alle unter Unix / Linux verfügbaren Kommandos auswendig kenne? Das ist schlicht und einfach unmöglich - es kommt ja mit jeder neuen Version einer Distri ein ganzer Schwarm neuer oder erweiterter Tools angeflattert. Natürlich hilft es, wenn man viele Tools kennt - man braucht nicht mehr so oft die Manual-Pages.

Wichtig ist, dass man sich in der Shell frei bewegen kann, also die grundlegenden Mechanismen kennt, wie Befehle ausgeführt werden, wie man sie zur Kommunikation überreden kann, wie man sie kontrolliert, wie die Steuerung in der Shell abläuft, wie man das überwachen kann. Steht alles in den Manuals und Info-Seiten ;-)

Und dabei hilft nur das Eine: Praxis - also ausprobieren, rumspielen mit den vielen Tools - ist spannender als jeder Ego-Shooter.

Jan

[jan61]

Moin,

einen hab ich noch: peschmae, Du musst einen ausgeben - Du hast eben Deinen 4.444en Beitrag verfasst - dat is ne Schnapszahl! Ich trinke Single-Malt - mindestens 16 Jahre alten :)

Gratulation!

Jan

[peschmae]

was meinst Du denn mit "inkonsistent"?

Naja, irgendwie hat schon jedes Dingelchen seinen eigenen Syntax erfunden... - das meine ich damit.



Nein, genau das muss man nicht. Eigentlich braucht man nur 2 Kommandos zu kennen: apropos und man. Danach braucht man nur noch lesen zu können - idealerweise auch in Englisch.


Um das Tool bedienen zu können reicht meist die Manpage. Aber damit du die Manpage überhaupt anguckst musst du:
1. wissen, dass es das konkrete Tool überhaupt gibt
2. vermuten, dass das Tool eventuell ein für das konkrete Problem nützliches Feature haben könnte (hier z.B. dass date nicht nur das aktuelle Datum ausgeben kann sondern auch andere Daten und das in so ziemlich jedem gewünschten Format...)



einen hab ich noch: peschmae, Du musst einen ausgeben - Du hast eben Deinen 4.444en Beitrag verfasst - dat is ne Schnapszahl! Ich trinke Single-Malt - mindestens 16 Jahre alten :)


Danke, danke! Ich auch. ;-)

MfG Peschmä

[jan61]

Moin,


Naja, irgendwie hat schon jedes Dingelchen seinen eigenen Syntax erfunden...

Na, so schlimm isses ja nun auch nicht. Es gibt einige Regeln, an die man sich schon halten kann - mit IMHO sehr seltenen Ausnahmen. Optionen fangen immer mit "-" (für lange Optionen mit "--") an (Ausnahmen hier: tar - wobei der auch das Minus versteht, date für das Format), Parameter zu Optionen kommen nach einem Leerzeichen dahinter (oder bei den langen Optionen nach einem "="), Argumente trennt man von den Optionen mit "--", Programme geben 0 für Erfolg und <> 0 bei einem Fehler zurück... Und wenn was nicht klappt, dann gibts ja immer noch die Manual-Page oder Info-Seite ;-)


Um das Tool bedienen zu können reicht meist die Manpage. Aber damit du die Manpage überhaupt anguckst musst du:
1. wissen, dass es das konkrete Tool überhaupt gibt

Dafür habe ich apropos genannt - nettes kleines lokales Suchmaschinchen. Beispiel für einen anderen Thread (Datei rückwärts ausgeben):

jan@jack:~/Development/du_tree> apropos -e cat reverse
cat (1) - concatenate files and print on the standard output
cat (1p) - concatenate and print files
avicat (1) - cat tool for joing files
tac (1) - concatenate and print files in reverse
col (1) - filter reverse line feeds from input
xxd (1) - make a hexdump or do the reverse.
rev (1) - reverse lines of a file
rman (1x) - reverse compile man pages from formatted form to a number of source formats

2. vermuten, dass das Tool eventuell ein für das konkrete Problem nützliches Feature haben könnte (hier z.B. dass date nicht nur das aktuelle Datum ausgeben kann sondern auch andere Daten und das in so ziemlich jedem gewünschten Format...)

Um diese Vermutungen zu erhärten, nimmt man eben man - und dann verfatzt man sich auf ein Terminal und probiert es durch. Ab und zu sind leider die schönen übersichtlichen Manual-Pages durch info ersetzt (bzw. die vollständigen Infos stehen nur dort - es hat sich wohl noch keiner getraut, gar kein Manual anzubieten ;-), na gut - dann tut man sich diese Monstrosität eben an und blättert darin. Und findet (wie bei date) da gleich tonnenweise Beispiele. Was braucht man mehr?

Jan

[peschmae]

Na, so schlimm isses ja nun auch nicht. Es gibt einige Regeln, an die man sich schon halten kann - mit IMHO sehr seltenen Ausnahmen. Optionen fangen immer mit "-" (für lange Optionen mit "--") an (Ausnahmen hier: tar - wobei der auch das Minus versteht, date für das Format), Parameter zu Optionen kommen nach einem Leerzeichen dahinter (oder bei den langen Optionen nach einem "="), Argumente trennt man von den Optionen mit "--", Programme geben 0 für Erfolg und <> 0 bei einem Fehler zurück... Und wenn was nicht klappt, dann gibts ja immer noch die Manual-Page oder Info-Seite ;-)


Einverstanden. Einige Konventionen gibts, an die sich zum Glück die meisten halten. Worauf ich vor allem hinaus wollte ist dass das ganze halt doch nicht soo konsistent ist wie das bei "richtigen" Programmiersprachen und Bibliotheken der Fall ist. Wenn sie gut gemacht sind.

Sobald etwas eine gewisse Komplexitätsgrenze erreicht hat nimmt man halt imo besser eine Scriptsprache, weil man sonst zuviel vom Aufwand damit verbrät den Output vom einen Tool so umzubüscheln dass der dann für das nächste Tool als Input gut ist. Dafür geht dann der Aufwand halt anderswo hin.

Was jetzt nicht heisst dass man nicht sehr viel auf der Shell sehr elegant lösen könnte. ;)



Dafür habe ich apropos genannt - nettes kleines lokales Suchmaschinchen. Beispiel für einen anderen Thread (Datei rückwärts ausgeben):


Hättest du nicht "reverse" sondern "inverse" oder "backwards" genommen hättest du genau nix gefunden. Also ausser asinhl() was erst noch kein Shelltool sondern eine C-Funktion ist. ;)

Dasselbe wenn du z.B. ein Tool gesucht hättest das noch gar nicht installiert war... (Ok, zugegebenermassen passiert das nicht soo oft, die Shell ist ziemlich komplett und in sich geschlossen)



Was braucht man mehr?


Nix. Ich sag nur dass es nicht einfach ist. Im Gegenteil. Oft sucht man sich nämlich einen Bär ab, macht ein Riesenkonstrukt und findet einen Monat später ein Tool dass das Ganze auf einer Zeile gemacht hätte. :)
Was mir in letzter Zeit aber immer seltener passiert weil ich die Tools langsam aber sicher etwas kenne (gut, mit AWK stehe ich immer noch auf Kriegsfuss, aber vor allem weil ich das zuwenig benutze)

MfG Peschmä

[jan61]

Moin,


Worauf ich vor allem hinaus wollte ist dass das ganze halt doch nicht soo konsistent ist wie das bei "richtigen" Programmiersprachen und Bibliotheken der Fall ist. Wenn sie gut gemacht sind.

Naja, diese Kriterien schränken aber z. B. auch in Java die Auswahl an "gut gemachten" Bibliotheken doch sehr ein ;-) Mal heißen die Getter "getSomeProperty()", mal sind das einfach die Property-Namen (Hashtable.keySet() z. B.), mal macht man eine Typkonvertierung per SomeClass.toInt(), mal heisst es Integer.intValue(), ... da kommt man (genau wie in der Shell) nicht ums Lesen der Doku rum.

Ich finde in dem Zusammenhang übrigens den Ansatz der Power-Shell von M$ sehr interessant, Objekte statt Strings in die Pipes zu schicken. Wobei sie dabei natürlich wie üblich kräftig bei der Shell, Perl ... geklaut haben.


Sobald etwas eine gewisse Komplexitätsgrenze erreicht hat nimmt man halt imo besser eine Scriptsprache, weil man sonst zuviel vom Aufwand damit verbrät den Output vom einen Tool so umzubüscheln dass der dann für das nächste Tool als Input gut ist. Dafür geht dann der Aufwand halt anderswo hin.

Das ist schon richtig - ich nehme auch für jede Aufgabe möglichst die am besten geeignete Scriptsprache (sofern ich sie kenne - bestimmte Sprachen mag ich eben nicht so - meist persönlicher Geschmack - ;-) - die Frage ist nur, was man als Scriptsprache akzeptiert. Tools wie awk oder sed haben ihre eigene Scriptsprache - man muss sie nur kennen bzw. ihre Manuals lesen. Sie sind in Perl-Zeiten etwas außer Mode gekommen, sind aber manchmal sogar noch einen Tick einfacher zu handhaben (und schneller). Ein gutes Beispiel ist der Thread http://www.mrunix.de/forums/showthread.php?t=59509 (Datei in Spalten schreiben): Im awk kann ich ohne Probleme auch nicht belegte Array-Elemente ansprechen, sie sind einfach leer. In Perl kriege ich Warnings (use of uninitialized value) um die Ohren gehauen und weiß nicht, was da rauskommt. Und ich habe schon einige Beispiele erlebt, wo awk deutlich schneller als Perl die gleiche Aufgabe erledigt hat.


Hättest du nicht "reverse" sondern "inverse" oder "backwards" genommen hättest du genau nix gefunden. Also ausser asinhl() was erst noch kein Shelltool sondern eine C-Funktion ist. ;)

Nun ja, apropos ist kein Google - aber das Grundproblem ist das Gleiche: man muss seine Anfrage geschickt stellen und ggf. mit anderen Begriffen wiederholen. Bei Google & Co. kriegst Du im Zweifelsfall zu viele oder unpassende Ergebnise, mit apropos keine. Und was die Sektion der gefundenen Ergebnisse angeht: die steht immer hinter dem gefundenen Befehl, was was ist, kriegt man mit man man raus ;-)


Oft sucht man sich nämlich einen Bär ab, macht ein Riesenkonstrukt und findet einen Monat später ein Tool dass das Ganze auf einer Zeile gemacht hätte. :)

Das ist mir auch schon oft passiert - ich finde das auch gar nicht so schlimm. Damit kriegt man nämlich Praxis, erweitert seinen Erfahrungsschatz und lernt, wie Probleme gelöst werden können (also, wie man an ein Problem herangeht, bevor man nach einem geeigneten Werkzeug sucht).


Was mir in letzter Zeit aber immer seltener passiert weil ich die Tools langsam aber sicher etwas kenne (gut, mit AWK stehe ich immer noch auf Kriegsfuss, aber vor allem weil ich das zuwenig benutze)

Dagegen hilft nur praktische Erfahrung. Ich z. B. habe awk lange vor Perl kennengelernt und deshalb erinnere ich mich gern an ihn ;-) Es gab sogar mal eine Zeit, wo ich der Meinung war (und diese auch öffentlich vertreten habe ;-), dass man nicht so viel in Perl rummachen, sondern sich eher auf die angestammten Unix-Bordmittel verlassen solle.

Jan

[peschmae]

Naja, diese Kriterien schränken aber z. B. auch in Java die Auswahl an "gut gemachten" Bibliotheken doch sehr ein ;-) Mal heißen die Getter "getSomeProperty()", mal sind das einfach die Property-Namen (Hashtable.keySet() z. B.), mal macht man eine Typkonvertierung per SomeClass.toInt(), mal heisst es Integer.intValue(), ... da kommt man (genau wie in der Shell) nicht ums Lesen der Doku rum.


Ja, da hast du recht. Dafür ist die Doku einfach zu bedienen und gut verlinkt. Das ist noch fast wichtiger... - und dadurch dass das ganze Objektorientiert ist, ist es in vielen Fällen auch einfacher nicht den Faden zu verlieren.



Ich finde in dem Zusammenhang übrigens den Ansatz der Power-Shell von M$ sehr interessant, Objekte statt Strings in die Pipes zu schicken. Wobei sie dabei natürlich wie üblich kräftig bei der Shell, Perl ... geklaut haben.


Hab ich mir noch nicht angeguckt. Da es das nicht für Linux und/oder als freie Software gibt ist mein Interesse auch gering ;)



Und was die Sektion der gefundenen Ergebnisse angeht: die steht immer hinter dem gefundenen Befehl, was was ist, kriegt man mit man man raus ;-)


Ja und wie kommst du jetzt darauf "man man" zu machen und nicht "man apropos"? Das wäre doch logischer ;)



Dagegen hilft nur praktische Erfahrung. ...

Womit du genau das sagst, was ich eigentlich am Anfang gesagt habe und womit du nicht einverstanden warst :D

Es ist halt wie bei vielen Diskussionen mit vernünftigen Leuten: Eigentlich meint man dasselbe nur formuliert mans anders, so dass es gegensätzlich erscheint... :)

MfG Peschmä

[jan61]

Moin,


Ja, da hast du recht. Dafür ist die Doku einfach zu bedienen und gut verlinkt. Das ist noch fast wichtiger... - und dadurch dass das ganze Objektorientiert ist, ist es in vielen Fällen auch einfacher nicht den Faden zu verlieren.

Jepp, Javadoc ist für mich auch die Luxuslimousine der Dokus - MSDN dagegen löst bei mir öfters mal Brechreiz aus ;-)


Hab ich mir noch nicht angeguckt. Da es das nicht für Linux und/oder als freie Software gibt ist mein Interesse auch gering ;)

Wo lebst Du? Schmeiss mal die allwissende Müllhalde mit den Suchbegriffen "Powershell Linux" an :D


Ja und wie kommst du jetzt darauf "man man" zu machen und nicht "man apropos"? Das wäre doch logischer ;)

Deshalb (Zitat aus "man apropos"):

SIEHE AUCH
whatis(1), man(1), mandb(8).
Ich weiß, das ist gemein - ich habe mir nämlich meine Argumente eben erst zusammengesucht :rolleyes: Aber Du musst schon zugeben: Wenn man nur die 2 Befehle kennt, liegt die Trefferquote für die richtige Man-Page bei 50% :p


Es ist halt wie bei vielen Diskussionen mit vernünftigen Leuten: Eigentlich meint man dasselbe nur formuliert mans anders, so dass es gegensätzlich erscheint... :)

Ich nie - ich meine immer das Gegenteil von dem, was ich bestreite, widerrufen zu haben :cool: - Jau, Du hast schon Recht, und wenn man sich mal zivilisiert drüber unterhält, dann versucht man auch, sich klarer auszudrücken - hilft nicht nur uns, sondern auch den Lesern, die gerade verzweifelt versuchen herauszufinden, warum wir überhaupt diskutieren ;-)

Jan

[peschmae]

Jepp, Javadoc ist für mich auch die Luxuslimousine der Dokus - MSDN dagegen löst bei mir öfters mal Brechreiz aus ;-)


Fast ne Luxuslimusine. Die Doku von Qt ist noch etwas besser, wegen dem Index und der Suchmaschine.



Wo lebst Du? Schmeiss mal die allwissende Müllhalde mit den Suchbegriffen "Powershell Linux" an :D


Ja den gibts ja sogar als Paket :D


peschmae@sid:~$ acs powershell
powershell - mächtiger Terminal-Emulator für GNOME
peschmae@sid:~$ acd powershell
Package: powershell
Priority: optional
Section: gnome
Installed-Size: 316
Maintainer: Uwe Hermann <uwe@debian.org>
Architecture: amd64
Source: powershell (0.9-8)
Version: 0.9-8+b1
Provides: x-terminal-emulator
Depends: gdk-imlib11, libart2 (>= 1.2.13-5), libaudiofile0 (>= 0.2.3-4), libc6 (
>= 2.6-1), libdb4.5, libesd0 (>= 0.2.35) | libesd-alsa0 (>= 0.2.35), libglib1.2l
dbl (>= 1.2.10-18), libgnome32 (>= 1.2.13-5), libgnomesupport0 (>= 1.2.13-5), li
bgnomeui32 (>= 1.4.2-3), libgtk1.2 (>= 1.2.10-4), libice6 (>= 1:1.0.0), libsm6,
libx11-6, libxext6, libxi6, libzvt2 (>= 1.4.1.3-3)
Filename: pool/main/p/powershell/powershell_0.9-8+b1_amd64.deb
Size: 80428
MD5sum: a5943d80ea6e02d0699319834a7dc451
SHA1: 1cc06b24c5ebdb91992bbc80e0a7eb0c1c9aad01
SHA256: 781de5938901e3b366f7bec96d4ffc0c5212e895440b6843e7 415951f1202c48
Description-de: mächtiger Terminal-Emulator für GNOME
PowerShell ist ein GNOME/Gtk+-basierender Terminal-Emulator, welcher viele Ter-
minals in einem einzigen Fenster unterstützt (nur durch das verfügbare RAM be-
grenzt). Jedes Terminal bekommt ein "Notizbuch"-Tab, welche das Umschalten
zwischen den Terminals einfach macht. PowerShell besitzt die Möglichkeit der
URL-Erkennung und Sachen wie Transparenz, Pixmap-Hintergründe usw.
Tag: interface::x11, role::plugin, suite::emacs, suite::gnome, uitoolkit::gtk, u
se::browsing, use::editing, x11::application, x11::terminal

peschmae@sid:~$


Wenn ich die G00glesche Müllhalde befrage dann finde ich unter anderem dich mit obigem Beitrag, aber nicht die MS Powershell für Linux ;)

Und natürlich ein paar hundert sf.net Projekte die was ähnliches für Linux machen möchten. ;)

Osh z.B. sieht auf den ersten Blick ganz nett aus, aber für den Alltag? Naja, müsste man wohl erst mal ausprobieren.



Deshalb (Zitat aus "man apropos"):
Ich weiß, das ist gemein - ich habe mir nämlich meine Argumente eben erst zusammengesucht :rolleyes: Aber Du musst schon zugeben: Wenn man nur die 2 Befehle kennt, liegt die Trefferquote für die richtige Man-Page bei 50% :p


Ja, das stimmt. Aber da muss man erst mal hingucken - und das in der Manpage zu man steht was der Output von apropos bedeutet ist weder intuitiv noch - Achtung, jetzt kommts! - konsistent ;)



Ich nie - ich meine immer das Gegenteil von dem, was ich bestreite, widerrufen zu haben :cool:

Jaja, ich auch. Nicht. Also ich hab nicht bestritten das nicht widerrufen zu haben.


sondern auch den Lesern, die gerade verzweifelt versuchen herauszufinden, warum wir überhaupt diskutieren ;-)

Ich glaub ich weiss wieso: Du möchtest mehr Beträge auf deinem Zähler haben als ich. Und du hast noch nicht gemerkt dass du diesbezüglich nicht weiterkommst wenn ich genau gleich viele Beiträge schreibe wie du. Oder so ähnlich - was weiss ich schon über deine Motivation.

Alles ist eben relativ ;)

MfG Peschmä