# Locale issue in FreeBSD 11.3-STABLE



## mercurius (Oct 28, 2019)

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...


```
[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


```
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


```
[mercurius@tyler ~]$ tmux
tmux: invalid LC_ALL, LC_CTYPE or LANG
```


----------



## SirDice (Oct 28, 2019)

Only set charset and lang. Don't set any of the others.


----------



## mercurius (Oct 28, 2019)

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):


```
[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=
```


----------



## T-Daemon (Oct 28, 2019)

Set in /etc/login.conf

```
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`

```
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=
```


----------



## mercurius (Oct 28, 2019)

I did this, but all LC_* are still C.... Looks like a bug 


```
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:
```


```
[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?


----------



## T-Daemon (Oct 28, 2019)

Check in /etc/master.passwd if the `:russian:` login class for the user is registered in the fifth field.


----------



## mercurius (Oct 28, 2019)

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.


----------



## T-Daemon (Oct 29, 2019)

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.


----------



## SirDice (Oct 29, 2019)

Did you run cap_mkdb(1) after you changed /etc/login.conf?


----------



## mercurius (Oct 29, 2019)

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.


----------



## mercurius (Oct 29, 2019)

T-Daemon said:


> 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


----------



## PMc (Oct 29, 2019)

mercurius said:


> 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.


----------



## mercurius (Oct 29, 2019)

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:

```
[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.


----------



## mercurius (Oct 29, 2019)

```
[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
```


----------



## PMc (Oct 30, 2019)

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:

```
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);
                }
```


----------



## T-Daemon (Oct 30, 2019)

The described problem couldn't be reproduced with a test installed FreeBSD-11.3-STABLE. This is the result:

`uname -a`

```
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

```
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`

```
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`

```
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.


----------



## mercurius (Oct 30, 2019)

PMc said:


> 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:
> ...



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.


----------



## mercurius (Oct 31, 2019)

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...


----------

