[flnews] Deutsche Meldung auf Terminal

[Marcel Logen]

Heute habe ich flnews mal wieder in der Eisenbahn
benutzt. Die Internetverbindung war relativ schlecht.

Mir fiel auf, daß flnews folgende Meldung (auf
deutsch (normalerweise erscheinen da nur engli-
sche Texte); mit den Fragezeichen) auf dem Termi-
nal ausgab:

| flnews: INET: Tempor??rer Fehler bei der Namensaufl??sung

Ich hatte flews so gestartet:

| ***@o15:~$ LC_MESSAGES=de_DE.UTF-8 flninst01030008/bin/flnews

Die locale-Einstellungen sind so:

| ***@o15:~$ locale
| LANG=C.UTF-8
| LANGUAGE=
| LC_CTYPE="C.UTF-8"
| LC_NUMERIC="C.UTF-8"
| LC_TIME="C.UTF-8"
| LC_COLLATE="C.UTF-8"
| LC_MONETARY="C.UTF-8"
| LC_MESSAGES="C.UTF-8"
| LC_PAPER="C.UTF-8"
| LC_NAME="C.UTF-8"
| LC_ADDRESS="C.UTF-8"
| LC_TELEPHONE="C.UTF-8"
| LC_MEASUREMENT="C.UTF-8"
| LC_IDENTIFICATION="C.UTF-8"
| LC_ALL=
| ***@o15:~$

Ich habe es anschließend so versucht, aber der Fehler
kam leider nicht mehr:

| ***@o15:~$ LC_MESSAGES=de_DE.UTF-8 LC_CTYPE=de_DE.UTF-8 flninst01030008/bin/flnews

Was ist die Ursache?

Im gesamten Quellcode konnte ich den String "Namensaufl"
nicht finden. Die Dateien "inet.c" und "inet.h" halfen mir
auch nicht weiter.

Vielleicht kommt die Meldung ja von einem anderen/externen
Programm und wird nur weitergereicht und von flnews aus-
gegeben. (?) Aber warum ist sie dann auf deutsch?

Marcel (Lines: 55)

[Peter J. Holzer]

Post by Marcel Logen
Mir fiel auf, daß flnews folgende Meldung (auf
deutsch (normalerweise erscheinen da nur engli-
sche Texte); mit den Fragezeichen) auf dem Termi-
| flnews: INET: Tempor??rer Fehler bei der Namensaufl??sung

Die Fehlermeldung kommt fast sicher nicht von flnews, sondern von der
libc.
Das besagt, dass Meldungen auf deutsch und in UTF-8 augegeben werden
sollen.

Die libc hält sich offensichtlich (und wenig überraschend) daran.

Aber wenn ein "ä" als zwei Zeichen (hier als "??" wiedergegeben)
dargestellt wird, ist das ein ziemlich sicheres Zeichen dafür, dass das
Terminal nicht auf UTF-8 eingestellt ist.

Die eigentliche Frage lautet also:

Welches Terminal verwendest Du und wie kannst Du das auf UTF-8
umstellen?

Oder alternativ: Warum versuchst Du mittels LC_MESSAGES der libc eine
andere Locale vorzugaukeln als auf Deinem System sinnvoll wäre?

hp

[Urs Janßen]

Post by Peter J. Holzer

Post by Marcel Logen
| flnews: INET: Tempor??rer Fehler bei der Namensaufl??sung

Die Fehlermeldung kommt fast sicher nicht von flnews, sondern von der
libc.

klint nach gai_strerror(3) auf EAI_AGAIN.

[Marcel Logen]

Post by Urs Janßen

Post by Peter J. Holzer

Post by Marcel Logen
| flnews: INET: Tempor??rer Fehler bei der Namensaufl??sung

Die Fehlermeldung kommt fast sicher nicht von flnews, sondern von der
libc.

klint nach gai_strerror(3) auf EAI_AGAIN.

Danke. Habe mal nachgesehen. Das wird es sein.

Marcel (Lines: 19)

[Michael Bäuerle]

Post by Marcel Logen

Post by Urs Janßen

Post by Peter J. Holzer

Post by Marcel Logen
| flnews: INET: Tempor??rer Fehler bei der Namensaufl??sung

Die Fehlermeldung kommt fast sicher nicht von flnews, sondern von der
libc.

klint nach gai_strerror(3) auf EAI_AGAIN.

Danke. Habe mal nachgesehen. Das wird es sein.

Das macht inet_name_resolver(), ein Wrapper für POSIX getaddrinfo(3).
Auf alten Systemen wird BSD gethostbyname(3) und getservbyname(3)
verwendet.

Die Daten von gai_strerror() werden auf das Terminal weitergeleitet.
Davor müsste die interne Fehlermeldung "getaddrinfo() failed" stehen.

Generell wirkt NLS bei flnews nur auf das GUI. Die Status- und Debug-
Informationen auf dem Terminal, die selbst erzeugt werden, werden nicht
umgesetzt. Das hier ist eine Ausnahme, weil nicht selbst erzeugt.

[Michael Bäuerle]

Post by Marcel Logen

Post by Urs Janßen

Post by Peter J. Holzer

Post by Marcel Logen
| flnews: INET: Tempor??rer Fehler bei der Namensaufl??sung

Die Fehlermeldung kommt fast sicher nicht von flnews, sondern von der
libc.

klint nach gai_strerror(3) auf EAI_AGAIN.

Danke. Habe mal nachgesehen. Das wird es sein.

Das macht inet_name_resolver(), ein Wrapper für POSIX getaddrinfo(3).
Auf alten Systemen wird BSD gethostbyname(3) und getservbyname(3)
verwendet.

Die Daten von gai_strerror() werden auf das Terminal weitergeleitet.
Davor müsste die interne Fehlermeldung "getaddrinfo() failed" stehen.

Generell wirkt NLS bei flnews nur auf das GUI. Die Status- und Debug-
Informationen auf dem Terminal, die selbst erzeugt werden, werden nicht
umgesetzt. Das hier ist eine Ausnahme, weil nicht selbst erzeugt.

Supersede:
Letzteres stimmt nicht, z.B. gibt es eine Sonderbehandlung, wenn ein
Regular Expression nicht compiliert werden kann. Damit ist das auch hier
sinnvoll.

In diesem Snapshot wird LC_MESSAGES für den Aufruf von gai_strerror()
auf "POSIX" gesetzt:
<https://micha.freeshell.org/flnews/src/flnews-1.3.0pre9.tar.bz2>
Size(flnews-1.3.0pre9.tar.bz2)= 1331993
SHA2-256(flnews-1.3.0pre9.tar.bz2)= b777359b28adfaab30a897aab5a914d19d5811886449c6645a418977685c98c1

Diese Fehlermeldung sollte jetzt ebenfalls in Englisch erscheinen.

[Marcel Logen]

Michael Bäuerle in de.comm.software.newsreader:

[...]

Post by Michael Bäuerle
Die Daten von gai_strerror() werden auf das Terminal weitergeleitet.
Davor müsste die interne Fehlermeldung "getaddrinfo() failed" stehen.

Das kann gut sein; ich meine, ich hätte das gesehen,
kann mich aber jetzt nicht mehr genau erinnern.

[...]

Post by Michael Bäuerle
In diesem Snapshot wird LC_MESSAGES für den Aufruf von gai_strerror()
<https://micha.freeshell.org/flnews/src/flnews-1.3.0pre9.tar.bz2>
Size(flnews-1.3.0pre9.tar.bz2)= 1331993
SHA2-256(flnews-1.3.0pre9.tar.bz2)= b777359b28adfaab30a897aab5a914d19d5811886449c6645a418977685c98c1
Diese Fehlermeldung sollte jetzt ebenfalls in Englisch erscheinen.

Danke. Wenn ich wieder im Zug unterwegs bin (und eine
schlechte Verbindung habe), werde ich das mal beobachten.

Marcel (Lines: 29)

[Marcel Logen]

Post by Marcel Logen

Post by Michael Bäuerle
In diesem Snapshot wird LC_MESSAGES für den Aufruf von gai_strerror()
<https://micha.freeshell.org/flnews/src/flnews-1.3.0pre9.tar.bz2>
Size(flnews-1.3.0pre9.tar.bz2)= 1331993
SHA2-256(flnews-1.3.0pre9.tar.bz2)= b777359b28adfaab30a897aab5a914d19d5811886449c6645a418977685c98c1
Diese Fehlermeldung sollte jetzt ebenfalls in Englisch erscheinen.

Danke. Wenn ich wieder im Zug unterwegs bin (und eine
schlechte Verbindung habe), werde ich das mal beobachten.

Gestern nachmittag war es wieder so weit.

Ich hatte im Zug eine schlechte Verbindung, und die Meldung
kam. Auf Englisch. Mit flnews pre9.

Danke noch mal.

Marcel 1j6l0 (1677984)

[Eike Rathke]

Post by Peter J. Holzer
Das besagt, dass Meldungen auf deutsch und in UTF-8 augegeben werden
sollen.
Aber wenn ein "ä" als zwei Zeichen (hier als "??" wiedergegeben)
dargestellt wird, ist das ein ziemlich sicheres Zeichen dafür, dass das
Terminal nicht auf UTF-8 eingestellt ist.

Doch, sein System ist ja auf UTF-8 eingestellt, aber eben auf "C.UTF-8"
und ein "C" locale ist ein POSIX Standard locale und beinhaltet nur
ASCII Zeichen, bei der Umkodierung von de_DE.UTF-8 nach C.UTF-8 für die
Ausgabe auf dem Terminal werden alle 8-bit Zeichen durch "?" ersetzt,
deswegen die UTF-8 Sequenz für "ä" durch "??".

Eike

[Marcel Logen]

Post by Eike Rathke

Post by Peter J. Holzer
Aber wenn ein "ä" als zwei Zeichen (hier als "??" wiedergegeben)
dargestellt wird, ist das ein ziemlich sicheres Zeichen dafür, dass das
Terminal nicht auf UTF-8 eingestellt ist.

Doch, sein System ist ja auf UTF-8 eingestellt, aber eben auf "C.UTF-8"
und ein "C" locale ist ein POSIX Standard locale und beinhaltet nur
ASCII Zeichen, bei der Umkodierung von de_DE.UTF-8 nach C.UTF-8 für die
Ausgabe auf dem Terminal werden alle 8-bit Zeichen durch "?" ersetzt,
deswegen die UTF-8 Sequenz für "ä" durch "??".

Im "GNOME-Terminal 3.46.8 for GNOME 43" ist "Unicode -
UTF-8" eingestellt (eben nachgesehen).

Die locale steht - wie geschrieben - auf "C.UTF-8".

Damit kann ich deutsche Umlaute auf dem Terminal ein-
und ausgeben.

| ***@o15:/tmp$ LC_ALL=C.UTF-8 echo äöü
| äöü
| ***@o15:/tmp$ LC_ALL=C echo äöü
| äöü
| ***@o15:/tmp$ LC_ALL=C äöü
| bash: äöü: command not found
| ***@o15:/tmp$ man gai_strerror
| ***@o15:/tmp$ LC_ALL=C printf '%s\n' 'äöü'
| äöü

Ganz klar ist mir aber noch nicht, warum es sich so
verhält, wie es sich verhält.

Marcel (Lines: 41)

[Eike Rathke]

Post by Marcel Logen
Im "GNOME-Terminal 3.46.8 for GNOME 43" ist "Unicode -
UTF-8" eingestellt (eben nachgesehen).
Die locale steht - wie geschrieben - auf "C.UTF-8".
Damit kann ich deutsche Umlaute auf dem Terminal ein-
und ausgeben.
| äöü

Und

LC_MESSAGES=de_DE.UTF-8 /usr/bin/printf '%d\n' 'äöü'

in dem Terminal wo C.UTF-8 gesetzt ist?
Gibt "normalerweise" immer noch
| /usr/bin/printf: ‘äöü’: expected a numeric value
aus.

Vermutung ist, dass flnews das irgendwie selber handelt und irgendwas
mit setlocale() treibt..

Eike

[Marcel Logen]

Post by Eike Rathke

Post by Marcel Logen
Im "GNOME-Terminal 3.46.8 for GNOME 43" ist "Unicode -
UTF-8" eingestellt (eben nachgesehen).
Die locale steht - wie geschrieben - auf "C.UTF-8".
Damit kann ich deutsche Umlaute auf dem Terminal ein-
und ausgeben.
| äöü

Und
LC_MESSAGES=de_DE.UTF-8 /usr/bin/printf '%d\n' 'äöü'
in dem Terminal wo C.UTF-8 gesetzt ist?
Gibt "normalerweise" immer noch
| /usr/bin/printf: ‘äöü’: expected a numeric value
aus.

| ***@o15:/tmp$ /usr/bin/printf '%d\n' 'äöü'
| /usr/bin/printf: ‘äöü’: expected a numeric value
| 0

| ***@o15:/tmp$ LC_MESSAGES=de_DE.UTF-8 /usr/bin/printf '%d\n' 'äöü'
| /usr/bin/printf: „äöü“: erwartet eine Zahlwert
| 0

| ***@o15:/tmp$ locale
| LANG=C.UTF-8
| LANGUAGE=
| LC_CTYPE="C.UTF-8"
| LC_NUMERIC="C.UTF-8"
| LC_TIME="C.UTF-8"
| LC_COLLATE="C.UTF-8"
| LC_MONETARY="C.UTF-8"
| LC_MESSAGES="C.UTF-8"
| LC_PAPER="C.UTF-8"
| LC_NAME="C.UTF-8"
| LC_ADDRESS="C.UTF-8"
| LC_TELEPHONE="C.UTF-8"
| LC_MEASUREMENT="C.UTF-8"
| LC_IDENTIFICATION="C.UTF-8"
| LC_ALL=

Ich blicke da jetzt nicht mehr ganz durch ...

Marcel (Lines: 57)

[Helmut Waitzmann]

Post by Eike Rathke

Post by Peter J. Holzer
Das besagt, dass Meldungen auf deutsch und in UTF-8 augegeben werden
sollen.
Aber wenn ein "ä" als zwei Zeichen (hier als "??"
wiedergegeben) dargestellt wird, ist das ein ziemlich sicheres
Zeichen dafür, dass das Terminal nicht auf UTF-8 eingestellt
ist.

Doch, sein System ist ja auf UTF-8 eingestellt, aber eben auf
"C.UTF-8" und ein "C" locale ist ein POSIX Standard locale und
beinhaltet nur ASCII Zeichen, bei der Umkodierung von
de_DE.UTF-8 nach C.UTF-8 für die Ausgabe auf dem Terminal werden
alle 8-bit Zeichen durch "?" ersetzt, deswegen die UTF-8 Sequenz
für "ä" durch "??".

Dann wäre Marcel geholfen, wenn er


LC_MESSAGES=de_DE.UTF-8 LC_CTYPE=de_DE.UTF-8 \
flninst01030008/bin/flnews


aufriefe?

[Marcel Logen]

Post by Helmut Waitzmann

Post by Eike Rathke
Doch, sein System ist ja auf UTF-8 eingestellt, aber eben auf "C.UTF-8"
und ein "C" locale ist ein POSIX Standard locale und beinhaltet nur ASCII
Zeichen, bei der Umkodierung von de_DE.UTF-8 nach C.UTF-8 für die Ausgabe
auf dem Terminal werden alle 8-bit Zeichen durch "?" ersetzt, deswegen
die UTF-8 Sequenz für "ä" durch "??".

Dann wäre Marcel geholfen, wenn er
LC_MESSAGES=de_DE.UTF-8 LC_CTYPE=de_DE.UTF-8 \
flninst01030008/bin/flnews
aufriefe?

"Geholfen" ist gut. :-)

Ich glaube, daß so eine 'durchgereichte' Meldung wie
bzgl. "EAI_AGAIN" (lt. Urs) hier im stationären Netz
nicht auftauchen wird. Im Zug wäre die Wahrschein-
lichkeit dafür wohl höher.

Davon abgesehen habe ich den ganzen Tag über flnews
schon so gestartet, wie Du es oben angegeben hast.

Mein Problem ist aber derzeit, daß ich beim locale-System
nicht richtig durchblicke: Ich habe den Eindruck, daß die
locale-Kategorien keine normalen oder Umgebungsvariablen
sind. Stimmt das?

Das wäre dann aber eher ein Thema für eine andere Gruppe.

Marcel (Lines: 40)

[Helmut Waitzmann]

Post by Marcel Logen

Post by Helmut Waitzmann

Post by Eike Rathke
Doch, sein System ist ja auf UTF-8 eingestellt, aber
eben auf "C.UTF-8" und ein "C" locale ist ein POSIX
Standard locale und beinhaltet nur ASCII Zeichen, bei
der Umkodierung von de_DE.UTF-8 nach C.UTF-8 für die
Ausgabe auf dem Terminal werden alle 8-bit Zeichen
durch "?" ersetzt, deswegen die UTF-8 Sequenz für "ä"
durch "??".

Dann wäre Marcel geholfen, wenn er
LC_MESSAGES=de_DE.UTF-8 LC_CTYPE=de_DE.UTF-8 \
flninst01030008/bin/flnews
aufriefe?

"Geholfen" ist gut. :-)

Das habe ich erwartet.

Post by Marcel Logen
Davon abgesehen habe ich den ganzen Tag über flnews
schon so gestartet, wie Du es oben angegeben hast.

Ja, das habe ich angenommen.  Aber Eikes Einlassung –
wenn sie denn relevant sein sollte – behauptete das
Gegenteil, und meine Frage sollte eher eine Gegenprobe
sein.

Post by Marcel Logen
Mein Problem ist aber derzeit, daß ich beim locale-System
nicht richtig durchblicke: Ich habe den Eindruck, daß die
locale-Kategorien keine normalen oder Umgebungsvariablen
sind. Stimmt das?

Die Locale‐Kategorien werden durch ganz normale
Umgebungsvariable (deren Namen nicht ganz zufällig genau
die Namen der Kategorien sind) beeinflusst.


Das Programm „locale“ gibt aus, wie die
Umgebungsvariablen die Kategorien beeinflussen.  Willst
du also wissen, wie dein Locale im Augenblick eingestellt
ist, mach es dir leicht und lass es dir mit dem Kommando


locale

zeigen.  (Eine Reihe von „printenv“‐Kommandos mit
Auswertung des jeweiligen Exit‐Status und der jeweiligen
Ausgabe könnte die Information auch ermitteln, ist aber
wesentlich umständlicher.)

[Marcel Logen]

Helmut Waitzmann in de.comm.software.newsreader:

[...]

Mein Problem ist aber derzeit, daß ich beim locale-System nicht richtig
durchblicke: Ich habe den Eindruck, daß die locale-Kategorien keine
normalen oder Umgebungsvariablen sind. Stimmt das?

Die Locale‐Kategorien werden durch ganz normale Umgebungsvariable (deren
Namen nicht ganz zufällig genau die Namen der Kategorien sind)
beeinflusst.

Das dachte ich bisher auch.

Das Programm „locale“ gibt aus, wie die Umgebungsvariablen die
Kategorien beeinflussen.  Willst du also wissen, wie dein Locale im
Augenblick eingestellt ist, mach es dir leicht und lass es dir mit dem
Kommando
locale
zeigen.

Ja, das mache ich auch immer so.

  (Eine Reihe von „printenv“‐Kommandos mit Auswertung des
jeweiligen Exit‐Status und der jeweiligen Ausgabe könnte die Information
auch ermitteln, ist aber wesentlich umständlicher.)

Was mich heute irritiert hat, ist folgendes:

| ***@o15:/tmp$ locale
| LANG=C.UTF-8
| LANGUAGE=
| LC_CTYPE="C.UTF-8"
| LC_NUMERIC="C.UTF-8"
| LC_TIME="C.UTF-8"
| LC_COLLATE="C.UTF-8"
| LC_MONETARY="C.UTF-8"
| LC_MESSAGES="C.UTF-8"
| LC_PAPER="C.UTF-8"
| LC_NAME="C.UTF-8"
| LC_ADDRESS="C.UTF-8"
| LC_TELEPHONE="C.UTF-8"
| LC_MEASUREMENT="C.UTF-8"
| LC_IDENTIFICATION="C.UTF-8"
| LC_ALL=
| ***@o15:/tmp$ printenv | grep -e 'LC_'
| ***@o15:/tmp$ echo "$LC_CTYPE" "$LC_MESSAGES"
|
| ***@o15:/tmp$

Bei "printenv" tauchen die "LC_"-Variablen gar nicht auf,
und auch mit "echo" werden deren Werte nicht ausgegeben.

Ich finde das seltsam. Entweder ist mein System (ein
erst vor einigen Wochen installiertes Debian/12.6) ver-
korkst, oder ich habe das locale-System nicht richtig
verstanden.

Marcel (Lines: 66)

[Urs Janßen]

Post by Marcel Logen
| LANG=C.UTF-8

beachte: keine anfuehrungszeichen drum

Post by Marcel Logen
| LC_CTYPE="C.UTF-8"

beachte: anfuehrungszeichen drum

Post by Marcel Logen
| LC_ALL=
|
Bei "printenv" tauchen die "LC_"-Variablen gar nicht auf,

sie sind ja auch nicht gesetzt.

Post by Marcel Logen
und auch mit "echo" werden deren Werte nicht ausgegeben.

passt doch, manpage nicht gelesen? locale(1):

| Values for variables set in the environment are printed without double
| quotes, implied values are printed with double quotes.

achja, LC_ALL geht vor LC_* geht vor LANG

Post by Marcel Logen
Ich finde das seltsam. Entweder ist mein System (ein
erst vor einigen Wochen installiertes Debian/12.6) ver-
korkst, oder ich habe das locale-System nicht richtig
verstanden.

letzteres. als "einstieg" locale(7) lesen und/oder
<https://pubs.opengroup.org/onlinepubs/9699919799/> 8.2

[Marcel Logen]

Urs Janßen in de.comm.software.newsreader:

[...]

Post by Urs Janßen

Post by Marcel Logen
Bei "printenv" tauchen die "LC_"-Variablen gar nicht auf,

sie sind ja auch nicht gesetzt.

Post by Marcel Logen
und auch mit "echo" werden deren Werte nicht ausgegeben.

| Values for variables set in the environment are printed without double
| quotes, implied values are printed with double quotes.

Grmpf, das hatte ich überlesen. Aber auch dann wäre
mir die Bedeutung von "implied" wohl nicht klar gewesen.

Post by Urs Janßen
achja, LC_ALL geht vor LC_* geht vor LANG

Post by Marcel Logen
Ich finde das seltsam. Entweder ist mein System (ein
erst vor einigen Wochen installiertes Debian/12.6) ver-
korkst, oder ich habe das locale-System nicht richtig
verstanden.

letzteres. als "einstieg" locale(7) lesen und/oder
<https://pubs.opengroup.org/onlinepubs/9699919799/> 8.2

Danke.

Marcel (Lines: 36)

[Marcel Logen]

Helmut Waitzmann in de.comm.software.newsreader:

[...]

Mein Problem ist aber derzeit, daß ich beim locale-System nicht richtig
durchblicke: Ich habe den Eindruck, daß die locale-Kategorien keine
normalen oder Umgebungsvariablen sind. Stimmt das?

Die Locale‐Kategorien werden durch ganz normale Umgebungsvariable (deren
Namen nicht ganz zufällig genau die Namen der Kategorien sind)
beeinflusst.

Das dachte ich bisher auch.

Das Programm „locale“ gibt aus, wie die Umgebungsvariablen die
Kategorien beeinflussen.  Willst du also wissen, wie dein Locale im
Augenblick eingestellt ist, mach es dir leicht und lass es dir mit dem
Kommando
locale
zeigen.

Ja, das mache ich auch immer so.

  (Eine Reihe von „printenv“‐Kommandos mit Auswertung des
jeweiligen Exit‐Status und der jeweiligen Ausgabe könnte die Information
auch ermitteln, ist aber wesentlich umständlicher.)

Was mich heute irritiert hat, ist folgendes:

| ***@o15:/tmp$ locale
| LANG=C.UTF-8
| LANGUAGE=
| LC_CTYPE="C.UTF-8"
| LC_NUMERIC="C.UTF-8"
| LC_TIME="C.UTF-8"
| LC_COLLATE="C.UTF-8"
| LC_MONETARY="C.UTF-8"
| LC_MESSAGES="C.UTF-8"
| LC_PAPER="C.UTF-8"
| LC_NAME="C.UTF-8"
| LC_ADDRESS="C.UTF-8"
| LC_TELEPHONE="C.UTF-8"
| LC_MEASUREMENT="C.UTF-8"
| LC_IDENTIFICATION="C.UTF-8"
| LC_ALL=
| ***@o15:/tmp$ printenv | grep -e 'LC_'
| ***@o15:/tmp$ echo "$LC_CTYPE" "$LC_MESSAGES"
|
| ***@o15:/tmp$

und

| ***@o15:/tmp$ declare -p LC_CTYPE
| bash: declare: LC_CTYPE: not found
| ***@o15:/tmp$ declare -x | grep -e 'LC_'
| ***@o15:/tmp$

Bei "printenv" tauchen die "LC_"-Variablen gar nicht auf,
und auch mit "echo" werden deren Werte nicht ausgegeben.

Ich finde das seltsam. Entweder ist mein System (ein
erst vor einigen Wochen installiertes Debian/12.6) ver-
korkst, oder ich habe das locale-System nicht richtig
verstanden.

Marcel (Lines: 75)

[supersedes]

[Helmut Waitzmann]

Post by Marcel Logen
[...]

Post by Helmut Waitzmann

Post by Marcel Logen
Mein Problem ist aber derzeit, daß ich beim locale-System
nicht richtig durchblicke: Ich habe den Eindruck, daß die
locale-Kategorien keine normalen oder Umgebungsvariablen sind.
Stimmt das?

Die Locale‐Kategorien werden durch ganz normale
Umgebungsvariable (deren Namen nicht ganz zufällig genau die
Namen der Kategorien sind) beeinflusst.

Das dachte ich bisher auch.

Post by Helmut Waitzmann
Das Programm „locale“ gibt aus, wie die Umgebungsvariablen die
Kategorien beeinflussen.  Willst du also wissen, wie dein
Locale im Augenblick eingestellt ist, mach es dir leicht und
lass es dir mit dem Kommando
locale
zeigen.

Ja, das mache ich auch immer so.

Post by Helmut Waitzmann
(Eine Reihe von „printenv“‐Kommandos mit Auswertung des
jeweiligen Exit‐Status und der jeweiligen Ausgabe könnte die
Information auch ermitteln, ist aber wesentlich umständlicher.)

| LANG=C.UTF-8
| LANGUAGE=
| LC_CTYPE="C.UTF-8"
| LC_NUMERIC="C.UTF-8"
| LC_TIME="C.UTF-8"
| LC_COLLATE="C.UTF-8"
| LC_MONETARY="C.UTF-8"
| LC_MESSAGES="C.UTF-8"
| LC_PAPER="C.UTF-8"
| LC_NAME="C.UTF-8"
| LC_ADDRESS="C.UTF-8"
| LC_TELEPHONE="C.UTF-8"
| LC_MEASUREMENT="C.UTF-8"
| LC_IDENTIFICATION="C.UTF-8"
| LC_ALL=
|
und
| bash: declare: LC_CTYPE: not found
Bei "printenv" tauchen die "LC_"-Variablen gar nicht auf,
und auch mit "echo" werden deren Werte nicht ausgegeben.

Dann sind sie auch nicht da.  „locale“ gibt die aus den
Umgebungsvariablen „LANG“ und „LC_…“ für die einzelnen Kategorien
effektiv ermittelten Locale‐Namen aus, nicht einfach die Werte
gewisser Umgebungsvariabler.


Alle diese Locale‐Kategorien „LC_…“ (ohne „LC_ALL“) ermitteln
ihren Locale‐Namen auf die folgende Weise:


Wenn die Umgebungsvariable „LC_ALL“ einen nicht‐leeren Inhalt hat,
gibt der den Locale‐Namen der Locale‐Kategorie an.


Andernfalls gibt die nach der Locale‐Kategorie benannte
Umgebungsvariable „LC_…“, falls sie einen nicht‐leeren Inhalt
hat, den Locale‐Namen der Kategorie an.


Andernfalls gibt die Umgebungsvariable „LANG“, falls sie einen
nicht‐leeren Inhalt hat, den Locale‐Namen der Kategorie an.


Andernfalls ist ein Default (ich glaube, „POSIX“) der Locale‐Name
der Kategorie.


Kurz:  Jede Kategorie sucht der Reihe nach, ob die
Umgebungsvariablen „LC_ALL“, „LC_<Name_der_Kategorie>“ oder
„LANG“ einen nicht‐leeren Inhalt haben, und nimmt den ersten, den
sie findet, als Suchergebnis, ansonsten ein Default.


„locale“ gibt für jede Kategorie das Ergebnis dieser Suche aus.


Auf meinem Debian‐System beschreiben die Manual‐Pages
„environ(7)“, „locale(7)“ und „locale(1)“ genaueres.


<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/locale.html#top>
im POSIX‐Standard ist auch lesenswert.

[Marcel Logen]

[...]

Post by Helmut Waitzmann

Bei "printenv" tauchen die "LC_"-Variablen gar nicht auf, und auch mit
"echo" werden deren Werte nicht ausgegeben.

Dann sind sie auch nicht da.  „locale“ gibt die aus den
Umgebungsvariablen „LANG“ und „LC_…“ für die einzelnen Kategorien
effektiv ermittelten Locale‐Namen aus, nicht einfach die Werte gewisser
Umgebungsvariabler.
Alle diese Locale‐Kategorien „LC_…“ (ohne „LC_ALL“) ermitteln ihren

[...]

Post by Helmut Waitzmann
Kurz:  Jede Kategorie sucht der Reihe nach, ob die Umgebungsvariablen
„LC_ALL“, „LC_<Name_der_Kategorie>“ oder „LANG“ einen nicht‐leeren
Inhalt haben, und nimmt den ersten, den sie findet, als Suchergebnis,
ansonsten ein Default.
„locale“ gibt für jede Kategorie das Ergebnis dieser Suche aus.

Danke.

Post by Helmut Waitzmann
Auf meinem Debian‐System beschreiben die Manual‐Pages „environ(7)“,
„locale(7)“ und „locale(1)“ genaueres.

OK, environ(7) habe ich mir noch nicht angesehen. Die
anderen hatte ich kursorisch gelesen.

Post by Helmut Waitzmann
<https://pubs.opengroup.org/onlinepubs/9699919799/utilities/locale.html#top>
im POSIX‐Standard ist auch lesenswert.

Ja. Davon gibt es BTW eine neuere Version:
<https://pubs.opengroup.org/onlinepubs/9799919799/utilities/locale.html>.

Marcel (Lines: 44)

[Peter J. Holzer]

Post by Eike Rathke

Post by Peter J. Holzer
Das besagt, dass Meldungen auf deutsch und in UTF-8 augegeben werden
sollen.
Aber wenn ein "ä" als zwei Zeichen (hier als "??" wiedergegeben)
dargestellt wird, ist das ein ziemlich sicheres Zeichen dafür, dass das
Terminal nicht auf UTF-8 eingestellt ist.

Doch, sein System ist ja auf UTF-8 eingestellt, aber eben auf "C.UTF-8"
und ein "C" locale ist ein POSIX Standard locale und beinhaltet nur
ASCII Zeichen,

Das trifft auf "C" zu, aber natürlich nicht auf "C.UTF-8". Das "UTF-8"
steht nicht nur zur Verzierung da.

Post by Eike Rathke
bei der Umkodierung von de_DE.UTF-8 nach C.UTF-8

Warum sollte da etwas umkodiert werden? Ist beide male die gleiche
Kodierung (UTF-8).

Post by Eike Rathke
für die Ausgabe auf dem Terminal werden alle 8-bit Zeichen durch "?"
ersetzt,

Du meinst "8 Bit Bytes". Denn in UTF-8 gibt es keine Zeichen, die 8 Bits
haben und keine gültigen ASCII-Zeichen sind (alle Nicht-ASCII-Zeichen
haben 16, 24 oder 32 Bit).

Post by Eike Rathke
deswegen die UTF-8 Sequenz für "ä" durch "??".

Ganz offensichtlich gibt es da irgendwas, das nicht erkennt, dass UTF-8
gewünscht ist (trotz Locale). Die Frage ist, was ist es und warum glaubt
das überhaupt, an Fehlermeldungen herumpfuschen zu müssen?

gai_strerror() ist es nicht:

% cat gai_strerror.c
#include <locale.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>

int main(void) {
setlocale(LC_ALL, "");
printf("%s\n", gai_strerror(EAI_AGAIN));
return 0;
}
% echo $LANG
C.UTF-8
% echo $LC_MESSAGES
de_DE.UTF-8
% ./gai_strerror
Temporärer Fehler bei der Namensauflösung

Oder vielleicht doch? Wenn ich LC_CTYPE falsch setze:

% export LC_CTYPE=C
% ./gai_strerror
Tempor?rer Fehler bei der Namensaufl?sung

dann werden die Umlaute durch ? ersetzt. Aber jeweils nur durch eines.

hp

[Michael Bäuerle]

Post by Peter J. Holzer
[...]
Ganz offensichtlich gibt es da irgendwas, das nicht erkennt, dass UTF-8
gewünscht ist (trotz Locale). Die Frage ist, was ist es und warum glaubt
das überhaupt, an Fehlermeldungen herumpfuschen zu müssen?
% cat gai_strerror.c
#include <locale.h>
#include <stdio.h>
#include <sys/types.h>
#include <sys/socket.h>
#include <netdb.h>
int main(void) {
setlocale(LC_ALL, "");
printf("%s\n", gai_strerror(EAI_AGAIN));
return 0;
}
% echo $LANG
C.UTF-8
% echo $LC_MESSAGES
de_DE.UTF-8
% ./gai_strerror
Temporärer Fehler bei der Namensauflösung
% export LC_CTYPE=C
% ./gai_strerror
Tempor?rer Fehler bei der Namensaufl?sung
dann werden die Umlaute durch ? ersetzt. Aber jeweils nur durch eines.

| $ gcc -o gai_strerror gai_strerror.c
| $ LC_MESSAGES=de_DE.utf8 ./gai_strerror
| Temporärer Fehler bei der Namensauflösung
| $ LC_ALL=C xterm

[ab jetzt in dem neuen xterm]

| $ LC_ALL=de_DE.utf8 ./gai_strerror
| Temporärer Fehler bei der Namensauflösung

Wenn das Terminal selbst nicht mit der passenden Locale gestartet wurde,
dann kann es die Ausgabe ggf. nicht anzeigen.

[Peter J. Holzer]

Post by Michael Bäuerle
| $ LC_ALL=C xterm
[ab jetzt in dem neuen xterm]
| $ LC_ALL=de_DE.utf8 ./gai_strerror
| Temporärer Fehler bei der Namensauflösung
Wenn das Terminal selbst nicht mit der passenden Locale gestartet wurde,
dann kann es die Ausgabe ggf. nicht anzeigen.

Klar. Das war ja meine erste Vermutung. Der OP sagt aber, dass das
Terminal auf UTF-8 eingestellt ist.

hp

[Eike Rathke]

Post by Peter J. Holzer

Post by Eike Rathke

Post by Peter J. Holzer
Aber wenn ein "ä" als zwei Zeichen (hier als "??" wiedergegeben)
dargestellt wird, ist das ein ziemlich sicheres Zeichen dafür, dass das
Terminal nicht auf UTF-8 eingestellt ist.

Doch, sein System ist ja auf UTF-8 eingestellt, aber eben auf "C.UTF-8"
und ein "C" locale ist ein POSIX Standard locale und beinhaltet nur
ASCII Zeichen,

Das trifft auf "C" zu, aber natürlich nicht auf "C.UTF-8". Das "UTF-8"
steht nicht nur zur Verzierung da.

Stimmt, da war ich abseits..

Eike

[Helmut Waitzmann]

Post by Eike Rathke
Doch, sein System ist ja auf UTF-8 eingestellt, aber eben auf
"C.UTF-8" und ein "C" locale ist ein POSIX Standard locale und
beinhaltet nur ASCII Zeichen, bei der Umkodierung von
de_DE.UTF-8 nach C.UTF-8 für die Ausgabe auf dem Terminal werden
alle 8-bit Zeichen durch "?" ersetzt, deswegen die UTF-8 Sequenz
für "ä" durch "??".

Alles, was ich auf die Schnelle an Ergebnissen einer Suchmaschine
im WWW über das Locale C.UTF-8 lesen konnte, erzählt mir, dass es
eine Erweiterung des Locales C ist: mit UTF-8 als Zeichensatz. 
Eingeschränkt sind nur range expressions bei den regular
expressions („[…-…]“):  Dort sind nur ASCII als Anfangs‐ und
Endpunkt zugelassen (ich vermute: weil die Sortierreihenfolge der
über den ASCII hinausgehenden UTF-8‐Zeichen nicht festgelegt
ist).


Daher sehe ich keinen Grund, warum etwa das Kommando


env LC_ALL=C.UTF-8 printf '%s\n' 'äöü'


in die Standard‐Ausgabe etwas anderes als „äöü“ ausgeben sollte. 
(Und das tut es auf meinem Debian‐10‐System auch nicht.)


Interessant ist vielleicht auch die Ausgabe des folgenden
Shell‐Kommandos, gestartet in einem UTF-8‐Locale:


(
for locale in de_DE.UTF-8 C.UTF-8 C
do
echo
(
set -x &&
env LC_CTYPE="$locale" locale -k -- charmap
) &&
printf '%s\n' 'äöü' |
(
set -x &&
env LC_CTYPE="$locale" iconv -f UTF-8 -t //TRANSLIT
)
done
)


Die Ausgabe:



+ env LC_CTYPE=de_DE.UTF-8 locale -k -- charmap
charmap="UTF-8"
+ env LC_CTYPE=de_DE.UTF-8 iconv -f UTF-8 -t //TRANSLIT
äöü

+ env LC_CTYPE=C.UTF-8 locale -k -- charmap
charmap="UTF-8"
+ env LC_CTYPE=C.UTF-8 iconv -f UTF-8 -t //TRANSLIT
äöü

+ env LC_CTYPE=C locale -k -- charmap
charmap="ANSI_X3.4-1968"
+ env LC_CTYPE=C iconv -f UTF-8 -t //TRANSLIT
???


Beobachtung:  Fragezeichen als Ausgabe entstehen nur bei der
Konversion der Umlaute mittels „//TRANSLIT“ in ein
Nicht‐UTF-8‐Locale (hier: das Locale „C“).

[Marcel Logen]

Post by Peter J. Holzer

Post by Marcel Logen
Mir fiel auf, daß flnews folgende Meldung (auf
deutsch (normalerweise erscheinen da nur engli-
sche Texte); mit den Fragezeichen) auf dem Termi-
| flnews: INET: Tempor??rer Fehler bei der Namensaufl??sung

Die Fehlermeldung kommt fast sicher nicht von flnews, sondern von der
libc.

So etwas hatte ich ja schon vermutet (siehe den letzten
Absatz in meinem Original-Posting):

| Vielleicht kommt die Meldung ja von einem anderen/externen
| Programm und wird nur weitergereicht und von flnews aus-
| gegeben. (?) Aber warum ist sie dann auf deutsch?

Jetzt ist mir auch klar, warum sie auf deutsch erscheint:
Du sagst ja, daß die libc sich an LC_MESSAGES hält.

Post by Peter J. Holzer
Das besagt, dass Meldungen auf deutsch und in UTF-8 augegeben werden
sollen.
Die libc hält sich offensichtlich (und wenig überraschend) daran.

Danke.

Post by Peter J. Holzer
Aber wenn ein "ä" als zwei Zeichen (hier als "??" wiedergegeben)
dargestellt wird, ist das ein ziemlich sicheres Zeichen dafür, dass das
Terminal nicht auf UTF-8 eingestellt ist.

| ***@o15:/tmp$ äöü
| bash: äöü: command not found

| ***@o15:/tmp$ locale
| LANG=C.UTF-8
| LANGUAGE=
| LC_CTYPE="C.UTF-8"
[...]

Post by Peter J. Holzer
Welches Terminal verwendest Du und wie kannst Du das auf UTF-8
umstellen?

Das GNOME-Terminal von Debian/12.6.

Post by Peter J. Holzer
Oder alternativ: Warum versuchst Du mittels LC_MESSAGES der libc eine
andere Locale vorzugaukeln als auf Deinem System sinnvoll wäre?

Das mache ich wegen des GUI von flnews, welches dann
alle Meldungen auf deutsch ausgibt. (Mir wäre es auch
egal, wenn flnews englisch sprechen würde, aber zu Test-
zwecken nutze ich halt das deutsche GUI.)

Marcel (Lines: 69)