FS#20911 - [initscripts] locale: fix inheritance
Attached to Project:
Arch Linux
Opened by Sébastien Luttringer (seblu) - Wednesday, 22 September 2010, 02:07 GMT
Last edited by Tom Gundersen (tomegun) - Sunday, 23 October 2011, 15:36 GMT
Opened by Sébastien Luttringer (seblu) - Wednesday, 22 September 2010, 02:07 GMT
Last edited by Tom Gundersen (tomegun) - Sunday, 23 October 2011, 15:36 GMT
|
Details
Description:
currently locales settings in rc.sysinit broke inheritance of locales settings. rc.sysinit create file in /etc/profile.d/locale.sh which set LANG environment variable to value setted in /etc/rc.conf. This cause a simple issue : Every time a profile is read by a shell, locale variable a overwritted. This is bad. Because: - It goes in reverse to a logical behaviour - Broke inheritance of /etc/environment variable which can be set by pam_env. - Give an inconsistant configuration if trying to change this value in X init script (because all running shell will be in rc.conf locale) - Configuration of non-standard locales schema cannot be clean (see example) - It's not elegant An example: someone want to have all messages in english but, all other locales for his country (france by example). Need to set all LC_* (except LC_ALL) to "fr_FR.UTF8" in /etc/environment. Or create a export in each config file of each shell it use to have his LANG set to french and LC_MESSAGES set to english. In a kiss approach, and i hope also better, profile.d just have to source /etc/environment and archlinux guide should set up locales in this file and not in rc.conf. rc.sysint can also use /etc/environment to know if it has to set console in UTF8 mode. I thinks rc.conf parameter have to set locale at start, not at any time a login shell is started. I can help if necessary. Additional info: * package version : 2010.07-1 |
This task depends upon
A quick search in gitweb shows that it already existed in 2005:
http://projects.archlinux.org/initscripts.git/commit/?id=39f5db6e89fd04da3979c11c3b2761ea031cd94d
You can browse related bugreports:
https://bugs.archlinux.org/index.php?string=locale.sh&project=1&search_in_comments=1&search_in_details=1&status%5B%5D=&do=index
for some comments about the reasons it exists.
Currently I am testing a couple of changes for locale configuration, but no guarantees.
If I understand correctly, the current locale.sh enables/disables utf8 every time a new shell is started. This seems wrong for two reasons: 1) What about before a shell is started? I.e. if you need to disable utf8 mode for your login. 2) You should only need to have to do it once.
Instead one could do (in addition to the change of mode of every tty as is currently done in rc.sysinit):
Change the variable /sys/module/vt/parameters/default_utf8 to enable/disable utf8 for new vc's.
My read confort my opinion! We can do things better, even if they was written at J.C. time (and it's your first bug fix). In a nutshell, several bugs come from a bad detection to why/when/where shell should or should not setting vc in utf8.
So, locale.sh do 2 things:
1 - it set locale
2 - if term is a VC it set utf8 mode.
Two, can be done really more genisouly by tom proposal. This is run at startup. One time. So simple! So beautiful!
We generally use shell in VT and not in VC. So trying to remove this 1% used line to set VC in utf8 sounds like a costless improvment.
About point one:
Tom give a really good new reason, login program should be aware of locale settings (one day maybe, it will speak french). And to follow this idea, when default shell is not a "shell" but a custom program which not source /etc/profile.d/locale.sh, it should also be aware of locales. Like it can know HOME or other parameters set by PAM process. Think to a perl or python script has default shell.
I can try to propose a patch, but if you are working on, it's great! :)
Any input on a proper solution would be appreciated. Maybe using pam? I guess the correct solution will be (as usual) to look at whatever everyone else is doing and see if someone has a nice solution for this.
This is not a linux philosophy. LANG setting can be per user / per program and can be changed when you want. Most DE allow user to configure LANG setting directly when they start it.
Think that reboot, kill uptime score. It's bad :) But here, question is not only about LANG settings.
Since you introduced DAEMON_LOCALE in /etc/rc.conf, I set it to ="yes", why not. Now, when starting system, I can observe such strange behaviour:
Udev starts, then fsck checks filesystems, says they are clean etc. It is problably done by /etc/rc.d/functions:
# Check local filesystems
fsck_all() {
fsck -A -T -C"$FSCK_FD" -a -t "no${NETFS//,/,no},noopts=_netdev" $FORCEFSCK
Fsck output is displayed as it supposed to be, translated, with national characters. Then, probably when next function form /etc/rc.d/functions is called, character encoding form fsck gets broken:
# Function for setting console font if required
set_consolefont()
...
My rc.conf:
LOCALE="pl_PL.utf8"
HARDWARECLOCK="UTC"
TIMEZONE="Europe/Warsaw"
KEYMAP="pl"
CONSOLEFONT="lat2-16"
CONSOLEMAP="8859-2"
USECOLOR="yes"
DAEMON_LOCALE="yes"