Discussion:
date in console
(zu alt für eine Antwort)
Jan Novak
2020-02-18 13:33:03 UTC
Permalink
Moin,

wo stelle ich denn ein, dass die "normale, unformatierte" Ausgabe von
"date" das hier ausgibt

Di 18. Feb 14:31:46 CET 2020

statt wie bisher das hier:

Tue 18 Feb 2020 02:31:53 PM CET


Jan
Andreas Kohlbach
2020-02-18 13:47:40 UTC
Permalink
Post by Jan Novak
wo stelle ich denn ein, dass die "normale, unformatierte" Ausgabe von
"date" das hier ausgibt
Di 18. Feb 14:31:46 CET 2020
Tue 18 Feb 2020 02:31:53 PM CET
Für die Bash in Debian

dpkg-reconfigure locales

Nachdem es durch ist, wird nach "Default" gefragt, so du Deutsch (oder
German?) wählst.
--
Andreas
Jens Schüßler
2020-02-18 13:48:22 UTC
Permalink
Post by Jan Novak
Moin,
wo stelle ich denn ein, dass die "normale, unformatierte" Ausgabe von
"date" das hier ausgibt
Di 18. Feb 14:31:46 CET 2020
:~$ LC_TIME=de_DE.UTF-8 date
Di 18. Feb 14:47:46 CET 2020
Post by Jan Novak
Tue 18 Feb 2020 02:31:53 PM CET
:~$ LC_TIME=C date
Tue Feb 18 14:46:42 CET 2020
Andreas Kohlbach
2020-02-18 15:27:17 UTC
Permalink
Post by Jens Schüßler
Post by Jan Novak
Moin,
wo stelle ich denn ein, dass die "normale, unformatierte" Ausgabe von
"date" das hier ausgibt
Di 18. Feb 14:31:46 CET 2020
:~$ LC_TIME=de_DE.UTF-8 date
Di 18. Feb 14:47:46 CET 2020
Post by Jan Novak
Tue 18 Feb 2020 02:31:53 PM CET
:~$ LC_TIME=C date
Tue Feb 18 14:46:42 CET 2020
Das überlebt keinen Reboot.
--
Andreas

PHP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0
Jens Schüßler
2020-02-18 16:02:54 UTC
Permalink
Post by Andreas Kohlbach
Post by Jens Schüßler
Post by Jan Novak
Moin,
wo stelle ich denn ein, dass die "normale, unformatierte" Ausgabe von
"date" das hier ausgibt
Di 18. Feb 14:31:46 CET 2020
:~$ LC_TIME=de_DE.UTF-8 date
Di 18. Feb 14:47:46 CET 2020
Post by Jan Novak
Tue 18 Feb 2020 02:31:53 PM CET
:~$ LC_TIME=C date
Tue Feb 18 14:46:42 CET 2020
Das überlebt keinen Reboot.
[ ] Du verstehst einen zielführenden Hinweis richtig zu deuten
Juergen Ilse
2020-02-18 16:55:10 UTC
Permalink
Hallo,
Post by Andreas Kohlbach
Post by Jens Schüßler
Post by Jan Novak
Moin,
wo stelle ich denn ein, dass die "normale, unformatierte" Ausgabe von
"date" das hier ausgibt
Di 18. Feb 14:31:46 CET 2020
:~$ LC_TIME=de_DE.UTF-8 date
Di 18. Feb 14:47:46 CET 2020
Post by Jan Novak
Tue 18 Feb 2020 02:31:53 PM CET
:~$ LC_TIME=C date
Tue Feb 18 14:46:42 CET 2020
Das überlebt keinen Reboot.
Doch, solange man bei jedem Aufruf von date das Environment passend setzt.
Ich halte diese Antwort fuer kompetenter als deine, weil aus deiner Antwort
nicht wirklich hervorgeht, welche Einstellung hier fuer das Datumsformat
verantwortlich ist. werden nur irgendwelche Defaults umgesetzt, die
letztendlich das Default-Environment auf dem System beeinflussen, ohne
genau aufzuzeigen, welche Einstellungen denn wie veraqendert wurden.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
--
Gib einem hungrigen einen Fisch und er ist einen Tag lang satt.
Zeig ihm, wie man angelt, und er wird dich beschimpfen und dir erklaeren,
dass er besseres zu tun habe, als dusselige Schnuere ins Wasser haengen
zu lassen ...
Andreas Kohlbach
2020-02-19 10:03:25 UTC
Permalink
Post by Juergen Ilse
Post by Andreas Kohlbach
Post by Jens Schüßler
Post by Jan Novak
Moin,
wo stelle ich denn ein, dass die "normale, unformatierte" Ausgabe von
"date" das hier ausgibt
Di 18. Feb 14:31:46 CET 2020
:~$ LC_TIME=de_DE.UTF-8 date
Di 18. Feb 14:47:46 CET 2020
Post by Jan Novak
Tue 18 Feb 2020 02:31:53 PM CET
:~$ LC_TIME=C date
Tue Feb 18 14:46:42 CET 2020
Das überlebt keinen Reboot.
Doch, solange man bei jedem Aufruf von date das Environment passend setzt.
Das ist genau mein Punkt. Jan ist nach meiner Einschätzung neu bei
Linux. Er wird vermutlich nicht wissen, wie man das macht und hier wieder
fragen.
Post by Juergen Ilse
Ich halte diese Antwort fuer kompetenter als deine, weil aus deiner Antwort
nicht wirklich hervorgeht, welche Einstellung hier fuer das Datumsformat
verantwortlich ist. werden nur irgendwelche Defaults umgesetzt, die
letztendlich das Default-Environment auf dem System beeinflussen, ohne
genau aufzuzeigen, welche Einstellungen denn wie veraqendert wurden.
Die Frage bleibt, ob Jan Einzelheiten wissen will, weil er sich mit Linux
beschäftigen will. Oder nur die Sprache umstellen. Im ersten Fall hast du
Recht.

Vielleicht hätte ich neben dpkg-reconfigure auch auf die Variablen eingehen
sollen.
--
Andreas

PGP fingerprint 952B0A9F12C2FD6C9F7E68DAA9C2EA89D1A370E0
Jan Novak
2020-02-19 10:18:59 UTC
Permalink
Post by Andreas Kohlbach
Das ist genau mein Punkt. Jan ist nach meiner Einschätzung neu bei
Linux. Er wird vermutlich nicht wissen, wie man das macht und hier wieder
fragen.
Bin zwar nicht neu bei Linux, dennoch hätte ich nicht weiter gefragt ;-)
Post by Andreas Kohlbach
Post by Juergen Ilse
Ich halte diese Antwort fuer kompetenter als deine, weil aus deiner Antwort
nicht wirklich hervorgeht, welche Einstellung hier fuer das Datumsformat
verantwortlich ist. werden nur irgendwelche Defaults umgesetzt, die
letztendlich das Default-Environment auf dem System beeinflussen, ohne
genau aufzuzeigen, welche Einstellungen denn wie veraqendert wurden.
Die Frage bleibt, ob Jan Einzelheiten wissen will, weil er sich mit Linux
beschäftigen will. Oder nur die Sprache umstellen. Im ersten Fall hast du
Recht.
Ehrlichgesagt interessiert mich zunächst einmal, dass das datum korrekt
angezeigt wird. Und mit der dpkg-reconfigure wird es korrekt gesetzt.
Das letztendlich eine Default-Environment Variable gsetzt wird, war zu
erwarten.
Das Date Format ist ja soweit klar, ebenso dass ich mir mit
date [+format wie auch immer ich es haben möchte]
die Ausgabe selber formatieren kann, auch.

Ich kam nur nicht selbst darauf, weil auf allen anderen Debian Maschiene
diese Einstellung beim installieren/konfigurieren richtig gesetzt
wurden. Nur eben bei dieser einen nicht.

Insofern, vielen Dank für den Tip.

Jan
Juergen Ilse
2020-02-18 16:48:32 UTC
Permalink
Hallo,
Post by Jan Novak
wo stelle ich denn ein, dass die "normale, unformatierte" Ausgabe von
"date" das hier ausgibt
Di 18. Feb 14:31:46 CET 2020
Tue 18 Feb 2020 02:31:53 PM CET
Das Format haengt von den locale-Einstellungen ab, genauer von der
Einstellung fuer LC_TIME:

***@mini:~$ LC_TIME=C date
Tue Feb 18 17:46:22 CET 2020
***@mini:~$ LC_TIME=de_DE.utf8 date
Di 18. Feb 17:46:25 CET 2020

"locale -a" sollte dir alle auf dem System verfuegbaren locale-Einstellungen
anzeigen ...

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)
Juergen Ilse
2020-02-18 17:06:08 UTC
Permalink
Hallo,
Post by Juergen Ilse
Das Format haengt von den locale-Einstellungen ab, genauer von der
Tue Feb 18 17:46:22 CET 2020
Di 18. Feb 17:46:25 CET 2020
"locale -a" sollte dir alle auf dem System verfuegbaren locale-Einstellungen
anzeigen ...
... und weil wir gerade beim Thema sind, noch eine Ergaenzung: Man sollte
*nicht* LC_ALL setzen (ausser, man ist sich ganz sicher, was man tut und
man ist sich ueber alle Konsequenzen im Klaren). Alle nicht explizit ge-
setzten locale-Einstellungen haben als "fallback" den Wert der Environment-
Variablen "LANG", also osllte man "LANG" auf den Wert setzen, den man gern
als Default haben moechte (fuer "alphabetische Sortierreihenfolge, Datums-
format, Defauklt-Waehrungssymbol, Sprache fuer Fehlermeldungen, ... was
auch immer). Mit den LC_* Environment-Variablen kann man dann einzelne
Einstellungen, fuer die man gern eine abweichende einstllung haette,
uebersteuern. LC_ALL sollte man deswegen i.a. *nicht* verwenden, weil
der Inhalt dieser Variablen (wenn sie gesetzt ist) *ALLE* locale Ein-
stellungen uebersteuert, auch wenn einzelne Einstellungen wie LC_TIME
oder LC_COLLATE bereits ausdruecklich auf andere Werte gesetzt sind.
Deswegen LC_ALL nur dann vrwenden, wenn man *genau* *weiss*, was man tut
und sich darueber im klaren ist, dass dann keine einzelnen locale-Ein-
stellungen mehr abweichend gesetzt werden koennen (weil alle durch den
Wert in LC_ALL uebersteuert werden).

Tschuess,
Juergen Ilse (***@useenet-verwaltung.de)
J***@fokus.fraunhofer.de
2020-02-19 10:14:31 UTC
Permalink
Post by Juergen Ilse
... und weil wir gerade beim Thema sind, noch eine Ergaenzung: Man sollte
*nicht* LC_ALL setzen (ausser, man ist sich ganz sicher, was man tut und
man ist sich ueber alle Konsequenzen im Klaren). Alle nicht explizit ge-
setzten locale-Einstellungen haben als "fallback" den Wert der Environment-
Variablen "LANG", also osllte man "LANG" auf den Wert setzen, den man gern
LANG ist ein Überbleibsel aus den Anfängen der Internationalisierung auf SunOS
aus der Zeit um 1986, als man noch nicht herausgefunden hatte, daß man die
Lokalen für unterschiedliche Kategorieren benötigt. LANG zu verwenden ist
eine schlechte Angewohnheit.

Die Saubere Methode ist jede Lokale-Kategorie einzeln zu setzen und bei Bedarf,
wenn man mal was testen will LC_ALL zu verwenden.
--
EMail:***@schily.net (home) Jörg Schilling D-13353 Berlin
***@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
Juergen Ilse
2020-02-19 11:48:19 UTC
Permalink
Hallo,
Post by J***@fokus.fraunhofer.de
Post by Juergen Ilse
... und weil wir gerade beim Thema sind, noch eine Ergaenzung: Man sollte
*nicht* LC_ALL setzen (ausser, man ist sich ganz sicher, was man tut und
man ist sich ueber alle Konsequenzen im Klaren). Alle nicht explizit ge-
setzten locale-Einstellungen haben als "fallback" den Wert der Environment-
Variablen "LANG", also osllte man "LANG" auf den Wert setzen, den man gern
LANG ist ein Überbleibsel aus den Anfängen der Internationalisierung auf SunOS
aus der Zeit um 1986, als man noch nicht herausgefunden hatte, daß man die
Lokalen für unterschiedliche Kategorieren benötigt.
s mag zwar sein, trotzdem ist LANG als Fallback fuer nicht einzeln gesetzte
Einstellungen durchaus sinnvoll.
Post by J***@fokus.fraunhofer.de
LANG zu verwenden ist eine schlechte Angewohnheit.
Das sehe ich anders (Gruende siehe oben). Es ist ein sinnvoller Fallback
fuer nicht separat gesetzte Einstellungen. Der Vorteil gegenueber LC_ALL
ist, dass man bei LANG einzelne Einstellungen mit persoenlichen Praeferenzen
uebersteuern kann. Bei LC_ALL ist das *nicht* moeglich.
Post by J***@fokus.fraunhofer.de
Die Saubere Methode ist jede Lokale-Kategorie einzeln zu setzen
Das kann man natuerlich machen. Warum aber sollte man es sich nicht
einfacher machen und LANG setzen (als "Default-Einstellung fuer alles,
was nicht explizit gesetzt wurde) und bei Bedarf einzelne Einstellungen
durch explizites setzen der entsprechenden LC_* Variablen ueberseteuern?
Post by J***@fokus.fraunhofer.de
und bei Bedarf, wenn man mal was testen will LC_ALL zu verwenden.
Das wiederum ist richtig, wenn man denn fuer den jeweiligen Test damit
leben kann, dass zwnagsweise alle Einstellungen auf den selben Wert
erfolgen.

Tschuess,
Juergen Ilse (***@usenet-verwaltung.de)

Loading...