Locale issue in FreeBSD 11.3-STABLE

I am trying to set locale on FreeBSD 11.3-STABLE. I used instructions from Handbook, but it works unproperly. Couldn't find where else to look...

Code:
[mercurius@tyler ~]$ locale
LANG=ru_RU.UTF-8
LC_CTYPE="C"
LC_COLLATE="C"
LC_TIME=C
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES=C
LC_ALL=

but, in /etc/login.conf

Code:
russian|Russian Users Accounts:\
        :charset=UTF-8:\
        :lang=ru_RU.UTF-8:\
        :setenv=LC_MESSAGES=C,LC_TIME=C,LC_COLLATE=ru_RU.UTF-8,LC_CTYPE=ru_RU.UTF-8,LC_MONETARY=ru_RU.UTF-8,LC_NUMERIC=ru_RU.UTF-8:\
        :tc=default:

I have 'russian' login class. I can't type in Russian (I am ssh`ing from another host because my FreeBSD host is headless), and when I try to run tmux, I got

Code:
[mercurius@tyler ~]$ tmux
tmux: invalid LC_ALL, LC_CTYPE or LANG
 
I need dates and messages in English, I don't like them in my language. In this case I have to set LC_MESSAGES and LC_TIME.

Also, I tried to set only charset and lang, it's still not working properly (but date shows time in my language):

Code:
[mercurius@tyler ~]$ locale
LANG=ru_RU.UTF-8
LC_CTYPE="C"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=
 
Set in /etc/login.conf
Code:
russian|Russian Users Accounts:\
    :charset=UTF-8:\
    :lang=ru_RU.UTF-8:\
    :setenv=LC_MESSAGES=en_US.UTF-8,LC_TIME=en_US.UTF-8:\
    :tc=default:
Run cap_mkdb /etc/login.conf.

locale
Code:
LANG=ru_RU.UTF-8
LC_CTYPE="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_TIME=en_US.UTF-8
LC_NUMERIC="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES=en_US.UTF-8
LC_ALL=
 
I did this, but all LC_* are still C.... Looks like a bug :(

Code:
russian|Russian Users Accounts:\
        :charset=UTF-8:\
        :lang=ru_RU.UTF-8:\
        :setenv=LC_MESSAGES=en_US.UTF-8,LC_TIME=en_US.UTF-8:\
        :tc=default:

Code:
[mercurius@tyler ~]$ locale
LANG=ru_RU.UTF-8
LC_CTYPE="C"
LC_COLLATE="C"
LC_TIME="C"
LC_NUMERIC="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=

it works properly in 12.0-RELEASE, but I have 11.3-STABLE now. Maybe a bug?
 
Yes, correct, it's in the fifth field.

I thought there are problems with my user and added one more user with russian login class. That user has the same problem.
 
You could try, if not done yet, update 11.3-STABLE to latest revision, see if problem persists. If persists open a PR.

You could also try the less suggested method by setting the variables in the shells global startup file as described in the handbook, depending on the shell used, in /etc/profile or /etc/csh.login.
 
Yes, I did. I am also trying another locales - for example, en_US.UTF-8, but LC_* variables are still C.
I consider this as a bug, I think I should report it to Bugzilla.

everything works in 12.0-RELEASE, I will try to investigate a little bit more.
 
You could try, if not done yet, update 11.3-STABLE to latest revision, see if problem persists. If persists open a PR.

You could also try the less suggested method by setting the variables in the shells global startup file as described in the handbook, depending on the shell used, in /etc/profile or /etc/csh.login.

Good idea, thanks! I will also try /etc/profile
 
I did this, but all LC_* are still C.... Looks like a bug :(

it works properly in 12.0-RELEASE, but I have 11.3-STABLE now. Maybe a bug?

I can get at least my desired LC_CTYPE from the setenv= parameter from /etc/login.conf in 11.2-RELEASE and 11.3-RELEASE. While there indeed might be a flaw in -STABLE, I would consider this a bit unlikely.

It might be that You have some contradictory settings in some other rc files, as there are lots of them loaded before the shell comes up. /etc/login.conf is the correct place because this is loaded most early, but then all others can overwrite these settings.

You can check with ps axleww to see which of the settings are given to a shell at the time of it`s invocation (before it loads the rc files).

I would suggest to first debug what is actually failing:
A) the locale propagation from /etc/login.conf to the shell
B) the russian login class.

Do so by putting some of the locale shellvars into setenv= of the default: stance of /etc/login.conf for a test.

Furthermore: the charset= parameter in /etc/login.conf is entirely irrelevant for this, It just sets MM_CHARSET, which was used for some mailers.
 
Thanks a lot for a proper explanation, it's really useful. I'm investigating.

As for shell variables, if I check them, I see that they are set correctly:
Code:
[mercurius@tyler ~]$ printenv | grep LC
LC_MESSAGES=en_US.UTF-8
LC_TIME=en_US.UTF-8

I tried to set them using default login class, they're set in shell, but locale command still reports that they all are C.
 
Code:
[mercurius@tyler /usr/src]$ ps axleww
<...>
1529 1047 1046   0  20  0  8016 4424 wait     Ss    0    0:00.39 USER=mercurius LOGNAME=mercurius HOME=/home/mercurius MAIL=/var/mail/mercurius PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/mercurius/bin TERM=rxvt-unicode LC_TIME=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 MM_CHARSET=UTF-8 LANG=ru_RU.UTF-8 SHELL=/usr/local/bin/bash SSH_CLIENT=172.19.4.1 56512 22 SSH_CONNECTION=172.19.4.1 56512 172.19.4.8 22 SSH_TTY=/dev/pts/0 -bash (bash)
1529 1164 1047   0  23  0  7448 3216 -        R+    0    0:00.03 SHELL=/usr/local/bin/bash CHARSET=UTF-8 EDITOR=vi ENV=/home/mercurius/.shrc PWD=/usr/src LOGNAME=mercurius HOME=/home/mercurius LANG=ru_RU.UTF-8 SSH_CONNECTION=172.19.4.1 56512 172.19.4.8 22 TERM=xterm-color USER=mercurius SHLVL=1 PAGER=more LC_MESSAGES=en_US.UTF-8 MM_CHARSET=UTF-8 SSH_CLIENT=172.19.4.1 56512 22 LC_TIME=en_US.UTF-8 PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/home/mercurius/bin MAIL=/var/mail/mercurius SSH_TTY=/dev/pts/0 OLDPWD=/usr/src/usr.bin _=/bin/ps ps axleww
 
This gives me riddles. It looks like it can't happen.
printenv should have the same values as locale. And in Your #1 post, it shows the explicitely configured values without "" - which just means they are explicitely configured and visible in the environment - but then the code (in /usr/src/usr.bin/locale/locale.c) would also verify that the environment value is identical to the printed value - which seems not to be the case.

This is beyond my understanding. Would somebody look at this and tell me how it can happen:
Code:
                vval = setlocale(lcinfo[i].id, NULL);
                eval = getenv(lcinfo[i].name);
                if (eval != NULL && !strcmp(eval, vval)
                                && strcmp(lang, vval)) {
                        printf("%s=%s\n", lcinfo[i].name, vval);
                } else {
                        printf("%s=\"%s\"\n", lcinfo[i].name, vval);
                }
 
The described problem couldn't be reproduced with a test installed FreeBSD-11.3-STABLE. This is the result:

uname -a
Code:
FreeBSD 11.3-S 11.3-STABLE FreeBSD 11.3-STABLE #0 r354051: Fri Oct 25 02:09:15 UTC 2019     root@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  amd64

/etc/login.conf
Code:
russian|Russian Users Accounts:\
    :charset=UTF-8:\
    :lang=ru_RU.UTF-8:\
    :setenv=LC_MESSAGES=en_US.UTF-8,LC_TIME=en_US.UTF-8:\
    :tc=default:

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

printenv | grep LC
Code:
LC_TIME=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8

What is interfering with the users locale environment variables affects your installation, not any.
 
This gives me riddles. It looks like it can't happen.
printenv should have the same values as locale. And in Your #1 post, it shows the explicitely configured values without "" - which just means they are explicitely configured and visible in the environment - but then the code (in /usr/src/usr.bin/locale/locale.c) would also verify that the environment value is identical to the printed value - which seems not to be the case.

This is beyond my understanding. Would somebody look at this and tell me how it can happen:
Code:
                vval = setlocale(lcinfo[i].id, NULL);
                eval = getenv(lcinfo[i].name);
                if (eval != NULL && !strcmp(eval, vval)
                                && strcmp(lang, vval)) {
                        printf("%s=%s\n", lcinfo[i].name, vval);
                } else {
                        printf("%s=\"%s\"\n", lcinfo[i].name, vval);
                }

Yes, I also looked to the code and could not understand why this problem happens. I will try to update to the next revision when it's out, or (because the host is freshly installed) reinstall the system.
 
it looks really, really strange. I reinstalled 11.3-RELEASE and have the same problem with locale.
May it be SPARC64 bug? No more ideas...

I can try to rebuild the whole system from source and see...
 
Back
Top