root-User und UTF-8

carver

Member
Frohe Ostern zusammen,

jetzt bin ich nicht so firm in Sachen Tagesbetrieb mit FreeBSD. Habe seit geraumer Zeit meinen Homeserver damit laufen (und zwar jederzeit absolut problemlos) und nun stellt sich mir eine Frage, deren Antwort ich womöglich durch mein Brett vor dem Kopf nicht sehe.
Der user root hat vermutlich aufgrund globaler default Werte folgende locales:

Code:
# locale
LANG=
LC_CTYPE="C"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=

Ich habe irgendwo gelesen, und da ich auf Infos aus irgendwelchen "gegoogelten" Quellen nicht immer allzu viel gebe, dass man für den root-Account die Login-Klasse nicht ändern und schon gar nicht auf UTF-8 stellen sollte. Eine Aussage, die das bestätigt, finde ich so im FreeBSD-Handbuch nicht.

Für die normalen User habe ich in der /etc/login.conf das hier verwendet:

Code:
german|German Users Accounts:\
    :charset=UTF-8:\
    :lang=de_DE.UTF-8:\
    :tc=default:

Habt ihr die locales von root auf UTF-8 geändert und wenn wie? Die Login-Klasse geändert? Wie würde diese dann korrekt für den root-Account aussehen?

Vielen Dank schonmal vorab und viele Grüße.
 
Ich habe selbst die default Login-Klasse auf UTF8 geändert. Also in der login.conf dort charset=UTF-8:\ :lang=de_DE.UTF-8:\ angefügt. Dass man den root-User nicht ändern sollte... nunja...FreeBSD-Leute sind gerne die altmodischen, ewig-gestrigen. ;) Ich mach das schon seit Jahren und hatte dort noch nie Probleme.

Was man bei root halt vermeiden sollte, eine Shell aus den Ports zu setzen. Sollte nämlich bei einem FreeBSD-Basisupdate die Shell wegen irgendwas nicht mehr funktionieren kannst du dich halt ohne weiteres nicht mehr einloggen. Ich hatte sowas mal auf den Raspberry Pi unter Linux. Dort hatte irgend ein Paket ARM-optimierte C-Routinen gepullt... nunja, als die dann nach dem Löschen nicht mehr da waren lief fast nichts mehr.
 
Das man den Root-User auf Locale "C" lassen soll, stammt noch aus der Zeit, als man seine Ports selber gebaut hat. Diverse schlechte Build-Systeme (Hallo Autobreak!) trennen sich nicht sauber von der Host-Umgebung, durch die veränderte Locale verhalten sich Dinge anders als gedacht und in der Folge fliegen Ports auf sehr interessant Weise auseinander. Heute, wo man hauptsächlich Pakete nutzt, stellt sich das Problem nicht mehr und es spricht (außer vielleicht der generellen Kritik an dem Encoding) nichts gegen UTF-8 für root.
 
Vielen Dank für die super schnellen und tollen Antworten.

Habe in der Datei /etc/login.conf die Klasse default mit den o.a. Zeilen ergänzt.
Sie sieht nun so aus:

Code:
default:\
        :passwd_format=sha512:\
        :copyright=/etc/COPYRIGHT:\
        :welcome=/etc/motd:\
        :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\
        :path=/sbin /bin /usr/sbin /usr/bin /usr/games /usr/local/sbin /usr/local/bin ~/bin:\
        :nologin=/var/run/nologin:\
        :cputime=unlimited:\
        :datasize=unlimited:\
        :stacksize=unlimited:\
        :memorylocked=64K:\
        :memoryuse=unlimited:\
        :filesize=unlimited:\
        :coredumpsize=unlimited:\
        :openfiles=unlimited:\
        :maxproc=unlimited:\
        :sbsize=unlimited:\
        :vmemoryuse=unlimited:\
        :swapuse=unlimited:\
        :pseudoterminals=unlimited:\
        :priority=0:\
        :ignoretime@:\
        :umask=022:\
        :charset=UTF-8:\
        :lang=de_DE.UTF-8:

Nun sieht die locale von root so aus:

Code:
# locale
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_ALL=

Umlaute usw. funktionieren nun. Nochmals Danke.
 
Da du bereits eine Definition für german in der login.conf hattest, hättest du auch diese für root benutzen können, wie du das für deine anderen User ja auch tust. Also, durch entsprechenden Eintrag in der /etc/master.passwd (mit vipw).
Die Variablen kannst du auch einzeln in der /etc/csh.cshrc (bzw jeweils in ~/.cshrc) oder den entsprechenden "profile" Dateien setzen. Siehe auch setlocale(3). Ebenso die charsets. Außerdem hast du ja auch eine ~/.login und ~/.login.conf
 
Man wechselt den root-User nicht aus dem Grund, dass wenig Frickl^WEntwickler wissen, dass solche Sachen wie
Code:
tr '[a-z]' '[A-Z]'
die man in configure-Skripten manchmal findet, den Source-Code frittieren können. Dies gilt insbesondere für das DE-Locale wo in [a-z] ein Buchstabe mehr ist, als [A-Z]. Na? Sich schon den "WTF" gerade gestellt?

Selbst überlegen oder wenn verzweifelt, hier die Auflösung:
Wie geht das deutsche Alphabet nochmal?

Code:
abc...pqrsßt...
ABC...PQRST...

Es gibt natürlich noch mehr generische Tools, die mit Lokalisierung anders funktionieren. Ich habe nur eines genannt, wo ich den Schmerz am eigenen Leibe gespürt habe. Deswegen... root immer "classic" Locale!
 
Nakal, mit dem »tr« unter Linux kann ich das jetzt nicht nachvollziehen. (FreeBSD habe ich momentan nicht.)
Das ist IMO ein Bug. In welcher FreeBSD-Version hast Du das beobachtet?

Oh, ich merke gerade, daß das »tr« von Linux (Debian Jessie) generell Probleme mit UTF-8-Zeichen hat:
Code:
$ tr 'äöüß' 'ÄÖÜ!'
ä
!�
äö
!�!�
ß
!!
 
Die upstream coreutils scheinen generell nicht vollständig Unicode-fähig zu sein (betrifft wohl hauptsächlich die Ausgabe). Fedora liefert wohl eine mittelschlecht gepatchte Version, die es halbwegs tut.

Betrifft nicht nur tr:
Code:
echo 哈哈 | cut -c 2-
��哈

Unter einem RedHat Derivat geht es.
 
Nach etwas Recherche: Coreutils unterstützt keine Multibyte Characters. D.h. nutzt man UTF-8, dann geht es nicht, benutzt man ISO, dann geht es (da nicht Multibyte). Es gibt wohl einen Plan, dass zu implementieren: http://www.pixelbeat.org/docs/coreutils_i18n/

Aber wie schon gesagt, FreeBSD hat dies Problem im speziellen nicht.

Aber auch FreeBSD ist da nicht ganz perfekt:

Code:
echo Straße | wc -m
7
 
Dass die Edit-Funktion so schnell abgeschaltet wird, ist doof xD Naja, jedenfalls hab ich das Problem mit echo gefunden. Man muss echo -n nutzen, sonst zählt er noch ein \n mit. Aber hier funktionieren coreutils und FreeBSD gleich.
 
Nakal, mit dem »tr« unter Linux kann ich das jetzt nicht nachvollziehen. (FreeBSD habe ich momentan nicht.)
Das ist IMO ein Bug. In welcher FreeBSD-Version hast Du das beobachtet?

Das ist kein Bug, das ist richtig. Ein "großes Eszett" gibt es nicht (das wird in "SS" umgewandelt, wenn alles groß geschrieben wird). Und wenn '[s-t]' in de_DE-Locale kein ß beinhaltet, dann ist das ein Bug in der Collation.

Das ist schon länger her, dass ich das beobachtet habe. Scheint mir, dass FreeBSD-Collation jetzt gerade kaputt ist. sort von diesen 5 Zeilen deutscher Wörter gibt mir:
Code:
affig
asiatisch
autonom
azentrisch
aßen

Bei locale:
Code:
LANG=de_DE.UTF-8
LC_CTYPE="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_ALL=
 
Ich weiß, dass es ein "großes Eszett" gibt, aber das ist in Deutschland nicht korrekt, es zu benutzen. Außerdem ist die Sortierung trotzdem falsch, unabhängig davon.
 
Das ist schon länger her, dass ich das beobachtet habe. Scheint mir, dass FreeBSD-Collation jetzt gerade kaputt ist.
Wenn du die neue Collation in 11-Current meinst, würde ich eine Bug-Report schreiben. Dann kannst du wenigstens sagen, dass es einen seit Jahren verrottenden Report gibt. ;)
 
Euer FreeBSD ist nicht unbedingt kaputt was die Sortierung angeht. Es ist eher so, dass jeder verschiedene Regeln hat.
In Deutschland wird das "ß" in der Regel alphabetisch nach dem "ss" sortiert. Der Duden sieht das sogar teils nach Ausgabe anders und sortiert es vorher ein.
Die Computerei sieht das historisch noch anders und zählt es zu den Umlauten und damit wird es später einsortiert.
So kommen Differenzen.
Somit ist das gezeigte Beispiel weiter oben sogar korrekt. Interessant ist es dann wie die Umlaute einsortiert werden.

Meiner Meinung bleibt es damit Fakt, dass root immer auf dem jeweiligem Standard des Systems bleiben sollte.
Nicht nur wegen den erwähnten Problemen bei Makefiles.
BSDs sind halt englischsprachige Systeme.

UTF-8 hat da noch lange nichts zu suchen.

(Und es wird immer ein Rätsel bleiben warum die Systeme immer noch verschiedene Implementierungen der locale verwenden, die alle was anderes machen. Vergleicht mal die Manuals mancher Systeme,)

Gruß
Chu
 
Ich hatte mit root UTF8 in den letzten Jahren vielleicht einmal Probleme. Das sollte IMHO schon gehen. Allerdings ist meine locale en_GB.UTF-8.
 
Zurück
Oben