[arch-projects] [initscripts][RFC][PATCH] locale.sh: add support for user-specific locale.conf, drop DAEMON_LOCALE
We use the first configuration file we find out of: * $XDG_CONFIG_HOME/locale.conf * /etc/locale.conf * /etc/rc.conf All subsequent config files are ignored. E.g., an emtpy /etc/locale.conf means that LOCALE from rc.conf is ignored. This will easily allow users to set one locale to be used for daemons/boot and a separate one to be used for users consoles etc. This eliminates the need for DAEMON_LOCALE, so remove that functionality. A post-install note will be added. The constraints that led to this suggestion: 1) The default locale should work even if locale-gen has not been run, i.e., it should be "C". 2) It is common to want the system locale to be "English", which a priori "C" satisfies. However, "C" is not UTF-8, which causes issues when the user locale is in UTF-8 (as it is the system locale that configures the console mode). 3) Users might (and often do) want a different locale than what is used system-wide. Moreover, different users might want different locales. In case this seems far-fetched: This computer is shared by two people neither of whose mother tongue is English (and whose mother tongue is not the same). I also want all my daemons to output in English so I can paste the output in bug reports etc. Signed-off-by: Tom Gundersen <teg@jklm.no> --- functions | 24 ++++++++---------------- locale.sh | 10 ++++++---- rc.conf.5.txt | 13 +++---------- 3 files changed, 17 insertions(+), 30 deletions(-) diff --git a/functions b/functions index e8ff7b8..7e7549a 100644 --- a/functions +++ b/functions @@ -9,7 +9,14 @@ localevars=(LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION LC_ALL) -vconsolevars=(KEYMAP KEYMAP_TOGGLE FONT FONT_MAP FONT_UNIMAP) + +# clear the TZ envvar, so daemons always respect /etc/localtime +unset TZ + +# sanitize the locale settings +unset "${localevars[@]}" + +. /etc/profile.d/locale.sh if [[ $1 == "start" ]]; then if [[ $STARTING ]]; then @@ -66,12 +73,6 @@ if (( $? != 3 )); then fi unset TERM_COLORS -# clear the TZ envvar, so daemons always respect /etc/localtime -unset TZ - -# sanitize the locale settings -unset "${localevars[@]}" - parse_envfile() { local file=$1 validkeys=("${@:2}") ret=0 lineno=0 key= val= local -r quotes=$'[\'"]' comments=$'[;#]*' @@ -723,15 +724,6 @@ if (( RC_FUNCTIONS_HOOK_FUNCS_DEFINED != 1 )); then declare -r RC_FUNCTIONS_HOOK_FUNCS_DEFINED=1 fi -if [[ $DAEMON_LOCALE != [nN][oO] ]]; then - export LANG=${LOCALE:-C} - if [[ -r /etc/locale.conf ]]; then - parse_envfile /etc/locale.conf "${localevars[@]}" - fi -else - export LANG=C -fi - # set colors if [[ $USECOLOR != [nN][oO] ]]; then if tput setaf 0 &>/dev/null; then diff --git a/locale.sh b/locale.sh index c465f6f..48c3c50 100644 --- a/locale.sh +++ b/locale.sh @@ -1,10 +1,12 @@ unset LANG -if [ -s /etc/locale.conf ]; then +if [ -s $XDG_CONFIG_HOME/locale.conf ]; then + . $XDG_CONFIG_HOME/locale.conf +elif [ -s $HOME/.config/locale.conf ]; then + . $HOME/.config/locale.conf +elif [ -s /etc/locale.conf ]; then . /etc/locale.conf -fi - -if [ -z "$LANG" ] && [ -s /etc/rc.conf ]; then +elif [ -s /etc/rc.conf ]; then LANG=$(. /etc/rc.conf 2>/dev/null; echo "$LOCALE") fi diff --git a/rc.conf.5.txt b/rc.conf.5.txt index 73c2423..8983871 100644 --- a/rc.conf.5.txt +++ b/rc.conf.5.txt @@ -190,21 +190,14 @@ FONT_MAP in /etc/vconsole.conf takes precedence (see vconsole.conf(5)), and is r This sets your system language, which will be used by all i18n-friendly applications and utilities. See `locale -a` (or locale.gen) for available options. -LANG in /etc/locale.conf takes precedence (see locale.conf(5)), and is recommended. +LANG in /etc/locale.conf takes precedence (see locale.conf(5)), and is recommended. User-specific +locale settings which override both /etc/locale.conf and /etc/rc.conf are set in +$XDG_CONFIG_HOME/locale.conf using the same syntax as /etc/locale.conf. If unset, it falls back to the C locale. LOCALE="en_US.UTF-8" -*DAEMON_LOCALE=* - - - If set to 'no', export the C locale to daemons and during the boot process. - - Otherwise, export LANG (or LOCALE) as configured in /etc/locale.conf (or /etc/rc.conf). - -Leave this unset, unless you have a specific reason to set it to 'no'. - - DAEMON_LOCALE="yes" - *USECOLOR=* Use ANSI color sequences in start-up messages, unless set to 'no'. -- 1.7.11.4
On Sat, Aug 11, 2012 at 07:53:34PM +0200, Tom Gundersen wrote:
We use the first configuration file we find out of:
* $XDG_CONFIG_HOME/locale.conf * /etc/locale.conf * /etc/rc.conf
All subsequent config files are ignored. E.g., an emtpy /etc/locale.conf means that LOCALE from rc.conf is ignored.
This will easily allow users to set one locale to be used for daemons/boot and a separate one to be used for users consoles etc.
This eliminates the need for DAEMON_LOCALE, so remove that functionality. A post-install note will be added.
The constraints that led to this suggestion:
1) The default locale should work even if locale-gen has not been run, i.e., it should be "C". 2) It is common to want the system locale to be "English", which a priori "C" satisfies. However, "C" is not UTF-8, which causes issues when the user locale is in UTF-8 (as it is the system locale that configures the console mode). 3) Users might (and often do) want a different locale than what is used system-wide. Moreover, different users might want different locales.
In case this seems far-fetched: This computer is shared by two people neither of whose mother tongue is English (and whose mother tongue is not the same). I also want all my daemons to output in English so I can paste the output in bug reports etc.
Signed-off-by: Tom Gundersen <teg@jklm.no> ---
Finally getting around to reviewing this. In short, this won't work. See below.
functions | 24 ++++++++---------------- locale.sh | 10 ++++++---- rc.conf.5.txt | 13 +++---------- 3 files changed, 17 insertions(+), 30 deletions(-)
diff --git a/functions b/functions index e8ff7b8..7e7549a 100644 --- a/functions +++ b/functions @@ -9,7 +9,14 @@ localevars=(LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION LC_ALL)
-vconsolevars=(KEYMAP KEYMAP_TOGGLE FONT FONT_MAP FONT_UNIMAP) + +# clear the TZ envvar, so daemons always respect /etc/localtime +unset TZ + +# sanitize the locale settings +unset "${localevars[@]}" + +. /etc/profile.d/locale.sh
This is going to read locale from root's home, if such a thing exists. An odd case perhaps, but do we really want this side effect?
if [[ $1 == "start" ]]; then if [[ $STARTING ]]; then @@ -66,12 +73,6 @@ if (( $? != 3 )); then fi unset TERM_COLORS
-# clear the TZ envvar, so daemons always respect /etc/localtime -unset TZ - -# sanitize the locale settings -unset "${localevars[@]}" - parse_envfile() { local file=$1 validkeys=("${@:2}") ret=0 lineno=0 key= val= local -r quotes=$'[\'"]' comments=$'[;#]*' @@ -723,15 +724,6 @@ if (( RC_FUNCTIONS_HOOK_FUNCS_DEFINED != 1 )); then declare -r RC_FUNCTIONS_HOOK_FUNCS_DEFINED=1 fi
-if [[ $DAEMON_LOCALE != [nN][oO] ]]; then - export LANG=${LOCALE:-C} - if [[ -r /etc/locale.conf ]]; then - parse_envfile /etc/locale.conf "${localevars[@]}" - fi -else - export LANG=C -fi - # set colors if [[ $USECOLOR != [nN][oO] ]]; then if tput setaf 0 &>/dev/null; then diff --git a/locale.sh b/locale.sh index c465f6f..48c3c50 100644 --- a/locale.sh +++ b/locale.sh @@ -1,10 +1,12 @@ unset LANG
-if [ -s /etc/locale.conf ]; then +if [ -s $XDG_CONFIG_HOME/locale.conf ]; then + . $XDG_CONFIG_HOME/locale.conf
This is a problem. I'm going to say that most of the time, XDG_CONFIG_HOME won't be defined here. We read iterate over /etc/profile.d in glob order (defined by current LC_COLLATE). If XDG_CONFIG_HOME is set by /etc/profile.d/xorg.sh, we aren't ever going to see this var defined. In addition, when XDG_CONFIG_HOME isn't defined, then under absurd circumstances, /locale.conf would be read. I think you meant to combine this case with the one below it for $HOME/config: if [ -s "${XDG_CONFIG_HOME:-$HOME/.config}/locale.conf" ]; then . "${XDG_CONFIG_HOME:-$HOME/.config}/locale.conf" fi But, again, with the current conditions, this just won't ever be defined. It's furthermore, impossible to set/override XDG_CONFIG_HOME in user config since it's all read post /etc/profile. Maybe we just stick to $HOME/.config/locale.conf?
+elif [ -s $HOME/.config/locale.conf ]; then + . $HOME/.config/locale.conf +elif [ -s /etc/locale.conf ]; then . /etc/locale.conf -fi - -if [ -z "$LANG" ] && [ -s /etc/rc.conf ]; then +elif [ -s /etc/rc.conf ]; then LANG=$(. /etc/rc.conf 2>/dev/null; echo "$LOCALE") fi
This means that /etc/rc.conf has the last say which is contrary to the documentation below. And, if /etc/rc.conf exists without LOCALE defined, you just set locale to an empty string.
diff --git a/rc.conf.5.txt b/rc.conf.5.txt index 73c2423..8983871 100644 --- a/rc.conf.5.txt +++ b/rc.conf.5.txt @@ -190,21 +190,14 @@ FONT_MAP in /etc/vconsole.conf takes precedence (see vconsole.conf(5)), and is r This sets your system language, which will be used by all i18n-friendly applications and utilities. See `locale -a` (or locale.gen) for available options.
-LANG in /etc/locale.conf takes precedence (see locale.conf(5)), and is recommended. +LANG in /etc/locale.conf takes precedence (see locale.conf(5)), and is recommended. User-specific +locale settings which override both /etc/locale.conf and /etc/rc.conf are set in +$XDG_CONFIG_HOME/locale.conf using the same syntax as /etc/locale.conf.
If unset, it falls back to the C locale.
LOCALE="en_US.UTF-8"
-*DAEMON_LOCALE=* - - - If set to 'no', export the C locale to daemons and during the boot process. - - Otherwise, export LANG (or LOCALE) as configured in /etc/locale.conf (or /etc/rc.conf). - -Leave this unset, unless you have a specific reason to set it to 'no'. - - DAEMON_LOCALE="yes" - *USECOLOR=*
Use ANSI color sequences in start-up messages, unless set to 'no'. -- 1.7.11.4
On Fri, Aug 24, 2012 at 10:23:43AM -0400, Dave Reisner wrote:
On Sat, Aug 11, 2012 at 07:53:34PM +0200, Tom Gundersen wrote:
We use the first configuration file we find out of:
* $XDG_CONFIG_HOME/locale.conf * /etc/locale.conf * /etc/rc.conf
All subsequent config files are ignored. E.g., an emtpy /etc/locale.conf means that LOCALE from rc.conf is ignored.
This will easily allow users to set one locale to be used for daemons/boot and a separate one to be used for users consoles etc.
This eliminates the need for DAEMON_LOCALE, so remove that functionality. A post-install note will be added.
The constraints that led to this suggestion:
1) The default locale should work even if locale-gen has not been run, i.e., it should be "C". 2) It is common to want the system locale to be "English", which a priori "C" satisfies. However, "C" is not UTF-8, which causes issues when the user locale is in UTF-8 (as it is the system locale that configures the console mode). 3) Users might (and often do) want a different locale than what is used system-wide. Moreover, different users might want different locales.
In case this seems far-fetched: This computer is shared by two people neither of whose mother tongue is English (and whose mother tongue is not the same). I also want all my daemons to output in English so I can paste the output in bug reports etc.
Signed-off-by: Tom Gundersen <teg@jklm.no> ---
Finally getting around to reviewing this. In short, this won't work. See below.
functions | 24 ++++++++---------------- locale.sh | 10 ++++++---- rc.conf.5.txt | 13 +++---------- 3 files changed, 17 insertions(+), 30 deletions(-)
diff --git a/functions b/functions index e8ff7b8..7e7549a 100644 --- a/functions +++ b/functions @@ -9,7 +9,14 @@ localevars=(LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION LC_ALL)
-vconsolevars=(KEYMAP KEYMAP_TOGGLE FONT FONT_MAP FONT_UNIMAP) + +# clear the TZ envvar, so daemons always respect /etc/localtime +unset TZ + +# sanitize the locale settings +unset "${localevars[@]}" + +. /etc/profile.d/locale.sh
This is going to read locale from root's home, if such a thing exists. An odd case perhaps, but do we really want this side effect?
if [[ $1 == "start" ]]; then if [[ $STARTING ]]; then @@ -66,12 +73,6 @@ if (( $? != 3 )); then fi unset TERM_COLORS
-# clear the TZ envvar, so daemons always respect /etc/localtime -unset TZ - -# sanitize the locale settings -unset "${localevars[@]}" - parse_envfile() { local file=$1 validkeys=("${@:2}") ret=0 lineno=0 key= val= local -r quotes=$'[\'"]' comments=$'[;#]*' @@ -723,15 +724,6 @@ if (( RC_FUNCTIONS_HOOK_FUNCS_DEFINED != 1 )); then declare -r RC_FUNCTIONS_HOOK_FUNCS_DEFINED=1 fi
-if [[ $DAEMON_LOCALE != [nN][oO] ]]; then - export LANG=${LOCALE:-C} - if [[ -r /etc/locale.conf ]]; then - parse_envfile /etc/locale.conf "${localevars[@]}" - fi -else - export LANG=C -fi - # set colors if [[ $USECOLOR != [nN][oO] ]]; then if tput setaf 0 &>/dev/null; then diff --git a/locale.sh b/locale.sh index c465f6f..48c3c50 100644 --- a/locale.sh +++ b/locale.sh @@ -1,10 +1,12 @@ unset LANG
-if [ -s /etc/locale.conf ]; then +if [ -s $XDG_CONFIG_HOME/locale.conf ]; then + . $XDG_CONFIG_HOME/locale.conf
This is a problem. I'm going to say that most of the time, XDG_CONFIG_HOME won't be defined here. We read iterate over /etc/profile.d in glob order (defined by current LC_COLLATE). If XDG_CONFIG_HOME is set by /etc/profile.d/xorg.sh, we aren't ever going to see this var defined.
In addition, when XDG_CONFIG_HOME isn't defined, then under absurd circumstances, /locale.conf would be read. I think you meant to combine this case with the one below it for $HOME/config:
if [ -s "${XDG_CONFIG_HOME:-$HOME/.config}/locale.conf" ]; then . "${XDG_CONFIG_HOME:-$HOME/.config}/locale.conf" fi
But, again, with the current conditions, this just won't ever be defined. It's furthermore, impossible to set/override XDG_CONFIG_HOME in user config since it's all read post /etc/profile.
Maybe we just stick to $HOME/.config/locale.conf?
+elif [ -s $HOME/.config/locale.conf ]; then + . $HOME/.config/locale.conf +elif [ -s /etc/locale.conf ]; then . /etc/locale.conf -fi - -if [ -z "$LANG" ] && [ -s /etc/rc.conf ]; then +elif [ -s /etc/rc.conf ]; then LANG=$(. /etc/rc.conf 2>/dev/null; echo "$LOCALE") fi
This means that /etc/rc.conf has the last say which is contrary to the documentation below. And, if /etc/rc.conf exists without LOCALE defined, you just set locale to an empty string.
Nevermind this, misread the if/elif.
diff --git a/rc.conf.5.txt b/rc.conf.5.txt index 73c2423..8983871 100644 --- a/rc.conf.5.txt +++ b/rc.conf.5.txt @@ -190,21 +190,14 @@ FONT_MAP in /etc/vconsole.conf takes precedence (see vconsole.conf(5)), and is r This sets your system language, which will be used by all i18n-friendly applications and utilities. See `locale -a` (or locale.gen) for available options.
-LANG in /etc/locale.conf takes precedence (see locale.conf(5)), and is recommended. +LANG in /etc/locale.conf takes precedence (see locale.conf(5)), and is recommended. User-specific +locale settings which override both /etc/locale.conf and /etc/rc.conf are set in +$XDG_CONFIG_HOME/locale.conf using the same syntax as /etc/locale.conf.
If unset, it falls back to the C locale.
LOCALE="en_US.UTF-8"
-*DAEMON_LOCALE=* - - - If set to 'no', export the C locale to daemons and during the boot process. - - Otherwise, export LANG (or LOCALE) as configured in /etc/locale.conf (or /etc/rc.conf). - -Leave this unset, unless you have a specific reason to set it to 'no'. - - DAEMON_LOCALE="yes" - *USECOLOR=*
Use ANSI color sequences in start-up messages, unless set to 'no'. -- 1.7.11.4
On Fri, Aug 24, 2012 at 4:23 PM, Dave Reisner <d@falconindy.com> wrote:
This is going to read locale from root's home, if such a thing exists. An odd case perhaps, but do we really want this side effect?
Hm, $HOME is set here...? How absurd. Good catch. I suppose we just want to unset $HOME? No, we don't want that side effect. On the other hand, we do not want to duplicate the code, so better find some way to make it work :)
-if [ -s /etc/locale.conf ]; then +if [ -s $XDG_CONFIG_HOME/locale.conf ]; then + . $XDG_CONFIG_HOME/locale.conf
This is a problem. I'm going to say that most of the time, XDG_CONFIG_HOME won't be defined here. We read iterate over /etc/profile.d in glob order (defined by current LC_COLLATE). If XDG_CONFIG_HOME is set by /etc/profile.d/xorg.sh, we aren't ever going to see this var defined.
The way XDG_* is set is just messed up. One might hope that one day it will be done better (say by a pam module). Shouldn't need to be part of xorg, it is useful even with no graphical login.
In addition, when XDG_CONFIG_HOME isn't defined, then under absurd circumstances, /locale.conf would be read. I think you meant to combine this case with the one below it for $HOME/config:
if [ -s "${XDG_CONFIG_HOME:-$HOME/.config}/locale.conf" ]; then . "${XDG_CONFIG_HOME:-$HOME/.config}/locale.conf" fi
But, again, with the current conditions, this just won't ever be defined. It's furthermore, impossible to set/override XDG_CONFIG_HOME in user config since it's all read post /etc/profile.
Maybe we just stick to $HOME/.config/locale.conf?
Might as well, we can add a comment about adding back XDG_CONFIG_HOME if it is ever likely to work. That said, I think your argument about reading /locale.conf would also apply to $HOME being unset (?), so we'd need to deal with that too. Thanks for the review, Tom
On Fri, Aug 24, 2012 at 06:16:43PM +0200, Tom Gundersen wrote:
On Fri, Aug 24, 2012 at 4:23 PM, Dave Reisner <d@falconindy.com> wrote:
This is going to read locale from root's home, if such a thing exists. An odd case perhaps, but do we really want this side effect?
Hm, $HOME is set here...? How absurd. Good catch. I suppose we just want to unset $HOME?
Ah, no nevermind... It's a non-interactive shell that was spawned by PID 1. HOME isn't going to be set here. A dump of the available environment just shows me: CONSOLE=/dev/console SHELL=/bin/sh TERM=linux INIT_VERSION=sysvinit-2.88 RD_TIMESTAMP= PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin RUNLEVEL=S PWD=/ LANG=C PREVLEVEL=N SYSTEMD_LOG_LEVEL=notice SHLVL=1 Still, I guess my point is that we should be testing for the presence of variables before trying to expand them. if [ -n "$HOME" ] && [ -s "$HOME/.config/locale.conf ]; then ...
No, we don't want that side effect. On the other hand, we do not want to duplicate the code, so better find some way to make it work :)
-if [ -s /etc/locale.conf ]; then +if [ -s $XDG_CONFIG_HOME/locale.conf ]; then + . $XDG_CONFIG_HOME/locale.conf
This is a problem. I'm going to say that most of the time, XDG_CONFIG_HOME won't be defined here. We read iterate over /etc/profile.d in glob order (defined by current LC_COLLATE). If XDG_CONFIG_HOME is set by /etc/profile.d/xorg.sh, we aren't ever going to see this var defined.
The way XDG_* is set is just messed up. One might hope that one day it will be done better (say by a pam module). Shouldn't need to be part of xorg, it is useful even with no graphical login.
I think other distros might order scripts by number. I've always thought that /etc/profile.d stuff is pretty ridiculous, but it's also roughly par for the course when you're talking about anything involving shell.
In addition, when XDG_CONFIG_HOME isn't defined, then under absurd circumstances, /locale.conf would be read. I think you meant to combine this case with the one below it for $HOME/config:
if [ -s "${XDG_CONFIG_HOME:-$HOME/.config}/locale.conf" ]; then . "${XDG_CONFIG_HOME:-$HOME/.config}/locale.conf" fi
But, again, with the current conditions, this just won't ever be defined. It's furthermore, impossible to set/override XDG_CONFIG_HOME in user config since it's all read post /etc/profile.
Maybe we just stick to $HOME/.config/locale.conf?
Might as well, we can add a comment about adding back XDG_CONFIG_HOME if it is ever likely to work. That said, I think your argument about reading /locale.conf would also apply to $HOME being unset (?), so we'd need to deal with that too.
Thanks for the review,
Tom
On Fri, Aug 24, 2012 at 7:02 PM, Dave Reisner <d@falconindy.com> wrote:
Still, I guess my point is that we should be testing for the presence of variables before trying to expand them.
if [ -n "$HOME" ] && [ -s "$HOME/.config/locale.conf ]; then
I agree. Will post a new version.
The way XDG_* is set is just messed up. One might hope that one day it will be done better (say by a pam module). Shouldn't need to be part of xorg, it is useful even with no graphical login.
I think other distros might order scripts by number. I've always thought that /etc/profile.d stuff is pretty ridiculous, but it's also roughly par for the course when you're talking about anything involving shell.
Sure, but most of these things are not shell-specific, so I hope something better will come along... -t
We use the first configuration file we find out of: * $XDG_CONFIG_HOME/locale.conf * /etc/locale.conf * /etc/rc.conf All subsequent config files are ignored. E.g., an emtpy /etc/locale.conf means that LOCALE from rc.conf is ignored. Note that currently $XDG_CONFIG_HOME is unlikely to be set when locale.sh is sourced, so it will not have any effect. In the future this might change, so we kept it in. This will easily allow users to set one locale to be used for daemons/boot and a separate one to be used for users consoles etc. This eliminates the need for DAEMON_LOCALE, so remove that functionality. A post-install note will be added. The constraints that led to this suggestion: 1) The default locale should work even if locale-gen has not been run, i.e., it should be "C". 2) It is common to want the system locale to be "English", which a priori "C" satisfies. However, "C" is not UTF-8, which causes issues when the user locale is in UTF-8 (as it is the system locale that configures the console mode). 3) Users might (and often do) want a different locale than what is used system-wide. Moreover, different users might want different locales. In case this seems far-fetched: This computer is shared by two people neither of whose mother tongue is English (and whose mother tongue is not the same). I also want all my daemons to output in English so I can paste the output in bug reports etc. v2: make sure $XDG_CONFIG_HOME and $HOME are set before using them Signed-off-by: Tom Gundersen <teg@jklm.no> --- functions | 24 ++++++++---------------- locale.sh | 10 ++++++---- rc.conf.5.txt | 13 +++---------- 3 files changed, 17 insertions(+), 30 deletions(-) diff --git a/functions b/functions index e8ff7b8..7e7549a 100644 --- a/functions +++ b/functions @@ -9,7 +9,14 @@ localevars=(LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT LC_IDENTIFICATION LC_ALL) -vconsolevars=(KEYMAP KEYMAP_TOGGLE FONT FONT_MAP FONT_UNIMAP) + +# clear the TZ envvar, so daemons always respect /etc/localtime +unset TZ + +# sanitize the locale settings +unset "${localevars[@]}" + +. /etc/profile.d/locale.sh if [[ $1 == "start" ]]; then if [[ $STARTING ]]; then @@ -66,12 +73,6 @@ if (( $? != 3 )); then fi unset TERM_COLORS -# clear the TZ envvar, so daemons always respect /etc/localtime -unset TZ - -# sanitize the locale settings -unset "${localevars[@]}" - parse_envfile() { local file=$1 validkeys=("${@:2}") ret=0 lineno=0 key= val= local -r quotes=$'[\'"]' comments=$'[;#]*' @@ -723,15 +724,6 @@ if (( RC_FUNCTIONS_HOOK_FUNCS_DEFINED != 1 )); then declare -r RC_FUNCTIONS_HOOK_FUNCS_DEFINED=1 fi -if [[ $DAEMON_LOCALE != [nN][oO] ]]; then - export LANG=${LOCALE:-C} - if [[ -r /etc/locale.conf ]]; then - parse_envfile /etc/locale.conf "${localevars[@]}" - fi -else - export LANG=C -fi - # set colors if [[ $USECOLOR != [nN][oO] ]]; then if tput setaf 0 &>/dev/null; then diff --git a/locale.sh b/locale.sh index c465f6f..e310318 100644 --- a/locale.sh +++ b/locale.sh @@ -1,10 +1,12 @@ unset LANG -if [ -s /etc/locale.conf ]; then +if [ -n $XDG_CONFIG_HOME ] && [ -s $XDG_CONFIG_HOME/locale.conf ]; then + . $XDG_CONFIG_HOME/locale.conf +elif [ -n $HOME ] && [ -s $HOME/.config/locale.conf ]; then + . $HOME/.config/locale.conf +elif [ -s /etc/locale.conf ]; then . /etc/locale.conf -fi - -if [ -z "$LANG" ] && [ -s /etc/rc.conf ]; then +elif [ -s /etc/rc.conf ]; then LANG=$(. /etc/rc.conf 2>/dev/null; echo "$LOCALE") fi diff --git a/rc.conf.5.txt b/rc.conf.5.txt index 73c2423..8983871 100644 --- a/rc.conf.5.txt +++ b/rc.conf.5.txt @@ -190,21 +190,14 @@ FONT_MAP in /etc/vconsole.conf takes precedence (see vconsole.conf(5)), and is r This sets your system language, which will be used by all i18n-friendly applications and utilities. See `locale -a` (or locale.gen) for available options. -LANG in /etc/locale.conf takes precedence (see locale.conf(5)), and is recommended. +LANG in /etc/locale.conf takes precedence (see locale.conf(5)), and is recommended. User-specific +locale settings which override both /etc/locale.conf and /etc/rc.conf are set in +$XDG_CONFIG_HOME/locale.conf using the same syntax as /etc/locale.conf. If unset, it falls back to the C locale. LOCALE="en_US.UTF-8" -*DAEMON_LOCALE=* - - - If set to 'no', export the C locale to daemons and during the boot process. - - Otherwise, export LANG (or LOCALE) as configured in /etc/locale.conf (or /etc/rc.conf). - -Leave this unset, unless you have a specific reason to set it to 'no'. - - DAEMON_LOCALE="yes" - *USECOLOR=* Use ANSI color sequences in start-up messages, unless set to 'no'. -- 1.7.12
On Fri, Aug 24, 2012 at 7:44 PM, Tom Gundersen <teg@jklm.no> wrote:
On Fri, Aug 24, 2012 at 7:02 PM, Dave Reisner <d@falconindy.com> wrote:
Still, I guess my point is that we should be testing for the presence of variables before trying to expand them.
if [ -n "$HOME" ] && [ -s "$HOME/.config/locale.conf ]; then
I agree. Will post a new version.
The way XDG_* is set is just messed up. One might hope that one day it will be done better (say by a pam module). Shouldn't need to be part of xorg, it is useful even with no graphical login.
I think other distros might order scripts by number. I've always thought that /etc/profile.d stuff is pretty ridiculous, but it's also roughly par for the course when you're talking about anything involving shell.
Sure, but most of these things are not shell-specific, so I hope something better will come along...
-t /etc/environment and ~/.pam_environment are loaded by pam_env. This handle all loading of env vars without focus on locales one.
The missing feature is a kind of env.d directory. Why not only drop all stuff based on scripts shell and use pam_env? -- Sébastien "Seblu" Luttringer www.seblu.net
On Tue, Aug 28, 2012 at 04:31:09PM +0200, Sébastien Luttringer wrote:
On Fri, Aug 24, 2012 at 7:44 PM, Tom Gundersen <teg@jklm.no> wrote:
On Fri, Aug 24, 2012 at 7:02 PM, Dave Reisner <d@falconindy.com> wrote:
Still, I guess my point is that we should be testing for the presence of variables before trying to expand them.
if [ -n "$HOME" ] && [ -s "$HOME/.config/locale.conf ]; then
I agree. Will post a new version.
The way XDG_* is set is just messed up. One might hope that one day it will be done better (say by a pam module). Shouldn't need to be part of xorg, it is useful even with no graphical login.
I think other distros might order scripts by number. I've always thought that /etc/profile.d stuff is pretty ridiculous, but it's also roughly par for the course when you're talking about anything involving shell.
Sure, but most of these things are not shell-specific, so I hope something better will come along...
-t /etc/environment and ~/.pam_environment are loaded by pam_env. This handle all loading of env vars without focus on locales one.
The missing feature is a kind of env.d directory.
Why not only drop all stuff based on scripts shell and use pam_env?
Sure, you can even do something like: session required pam_env.so conffile=/dev/null envfile=/etc/locale.conf user_envfile=.config/locale.conf But, pam_env has no ability to filter/allow a specific set of variables. You could put anything you want in here. d
On Tue, Aug 28, 2012 at 4:40 PM, Dave Reisner <d@falconindy.com> wrote:
On Tue, Aug 28, 2012 at 04:31:09PM +0200, Sébastien Luttringer wrote:
On Fri, Aug 24, 2012 at 7:44 PM, Tom Gundersen <teg@jklm.no> wrote:
On Fri, Aug 24, 2012 at 7:02 PM, Dave Reisner <d@falconindy.com> wrote:
Still, I guess my point is that we should be testing for the presence of variables before trying to expand them.
if [ -n "$HOME" ] && [ -s "$HOME/.config/locale.conf ]; then
I agree. Will post a new version.
The way XDG_* is set is just messed up. One might hope that one day it will be done better (say by a pam module). Shouldn't need to be part of xorg, it is useful even with no graphical login.
I think other distros might order scripts by number. I've always thought that /etc/profile.d stuff is pretty ridiculous, but it's also roughly par for the course when you're talking about anything involving shell.
Sure, but most of these things are not shell-specific, so I hope something better will come along...
-t /etc/environment and ~/.pam_environment are loaded by pam_env. This handle all loading of env vars without focus on locales one.
The missing feature is a kind of env.d directory.
Why not only drop all stuff based on scripts shell and use pam_env?
Sure, you can even do something like:
session required pam_env.so conffile=/dev/null envfile=/etc/locale.conf user_envfile=.config/locale.conf
But, pam_env has no ability to filter/allow a specific set of variables. conffile allow to filter specific set of variables.
You could put anything you want in here. Where the magic begin. If all requirement are met, we can drop all
from pam_env.conf manual: The /etc/security/pam_env.conf file specifies the environment variables to be set, unset or modified by pam_env(8) profile.d crap. -- Sébastien "Seblu" Luttringer www.seblu.net
On Tue, Aug 28, 2012 at 04:50:44PM +0200, Sébastien Luttringer wrote:
On Tue, Aug 28, 2012 at 4:40 PM, Dave Reisner <d@falconindy.com> wrote:
On Tue, Aug 28, 2012 at 04:31:09PM +0200, Sébastien Luttringer wrote:
On Fri, Aug 24, 2012 at 7:44 PM, Tom Gundersen <teg@jklm.no> wrote:
On Fri, Aug 24, 2012 at 7:02 PM, Dave Reisner <d@falconindy.com> wrote:
Still, I guess my point is that we should be testing for the presence of variables before trying to expand them.
if [ -n "$HOME" ] && [ -s "$HOME/.config/locale.conf ]; then
I agree. Will post a new version.
The way XDG_* is set is just messed up. One might hope that one day it will be done better (say by a pam module). Shouldn't need to be part of xorg, it is useful even with no graphical login.
I think other distros might order scripts by number. I've always thought that /etc/profile.d stuff is pretty ridiculous, but it's also roughly par for the course when you're talking about anything involving shell.
Sure, but most of these things are not shell-specific, so I hope something better will come along...
-t /etc/environment and ~/.pam_environment are loaded by pam_env. This handle all loading of env vars without focus on locales one.
The missing feature is a kind of env.d directory.
Why not only drop all stuff based on scripts shell and use pam_env?
Sure, you can even do something like:
session required pam_env.so conffile=/dev/null envfile=/etc/locale.conf user_envfile=.config/locale.conf
But, pam_env has no ability to filter/allow a specific set of variables. conffile allow to filter specific set of variables.
from pam_env.conf manual: The /etc/security/pam_env.conf file specifies the environment variables to be set, unset or modified by pam_env(8)
Nothing about the text that follows in the manpage describes how to _limit_ the variables that can be set in the environment file. It only describes defaults and overrides. I've perused the code as well. I have yet to find this fabled whitelist.
You could put anything you want in here. Where the magic begin. If all requirement are met, we can drop all profile.d crap.
Lots of profile.d scripts contain conditional logic. Whether or not this is right, there is no substitute for it in pam_env.
On Tue, Aug 28, 2012 at 4:59 PM, Dave Reisner <d@falconindy.com> wrote:
On Tue, Aug 28, 2012 at 04:50:44PM +0200, Sébastien Luttringer wrote:
On Tue, Aug 28, 2012 at 4:40 PM, Dave Reisner <d@falconindy.com> wrote:
On Tue, Aug 28, 2012 at 04:31:09PM +0200, Sébastien Luttringer wrote:
On Fri, Aug 24, 2012 at 7:44 PM, Tom Gundersen <teg@jklm.no> wrote:
On Fri, Aug 24, 2012 at 7:02 PM, Dave Reisner <d@falconindy.com> wrote:
Still, I guess my point is that we should be testing for the presence of variables before trying to expand them. from pam_env.conf manual: The /etc/security/pam_env.conf file specifies the environment variables to be set, unset or modified by pam_env(8)
Nothing about the text that follows in the manpage describes how to _limit_ the variables that can be set in the environment file. It only describes defaults and overrides. I've perused the code as well. I have yet to find this fabled whitelist. ok I was a bit enthusiastic reading the man page. My bad.
But why would we filter variables defined in /etc/environment? After all, LANG and LC_* are environment variables why would they have the privilege of having a separate configuration file? mkinipcio/systemd can look into /etc/environment instead of /etc/locale.conf. I'm wondering why systemd don't do this. Any thought?
You could put anything you want in here. Where the magic begin. If all requirement are met, we can drop all profile.d crap.
Lots of profile.d scripts contain conditional logic. Whether or not this is right, there is no substitute for it in pam_env.
That's an issue. I found more interesting to fix this in pam_env rather than to lug shell scripts to source variables without conditions. -- Sébastien "Seblu" Luttringer www.seblu.net
On Fri, Aug 31, 2012 at 4:17 PM, Sébastien Luttringer <seblu@seblu.net> wrote:
On Tue, Aug 28, 2012 at 4:59 PM, Dave Reisner <d@falconindy.com> wrote:
On Tue, Aug 28, 2012 at 04:50:44PM +0200, Sébastien Luttringer wrote:
On Tue, Aug 28, 2012 at 4:40 PM, Dave Reisner <d@falconindy.com> wrote:
On Tue, Aug 28, 2012 at 04:31:09PM +0200, Sébastien Luttringer wrote:
On Fri, Aug 24, 2012 at 7:44 PM, Tom Gundersen <teg@jklm.no> wrote:
On Fri, Aug 24, 2012 at 7:02 PM, Dave Reisner <d@falconindy.com> wrote: > Still, I guess my point is that we should be testing for the presence of > variables before trying to expand them. from pam_env.conf manual: The /etc/security/pam_env.conf file specifies the environment variables to be set, unset or modified by pam_env(8)
Nothing about the text that follows in the manpage describes how to _limit_ the variables that can be set in the environment file. It only describes defaults and overrides. I've perused the code as well. I have yet to find this fabled whitelist. ok I was a bit enthusiastic reading the man page. My bad.
But why would we filter variables defined in /etc/environment? After all, LANG and LC_* are environment variables why would they have the privilege of having a separate configuration file?
Looking into debian pam settings, I read this. # locale variables are also kept into /etc/default/locale in etch # reading this file *in addition to /etc/environment* does not hurt session required pam_env.so readenv=1 envfile=/etc/default/locale They use pam_env to load locale. -- Sébastien "Seblu" Luttringer www.seblu.net
participants (3)
-
Dave Reisner
-
Sébastien Luttringer
-
Tom Gundersen