Re: Locales in a Guix container (somewhat related to r-readr)?

[zimoun]

Dear,

On Thu, 20 Feb 2020 at 16:42, Wiktor Żelazny <address@hidden> wrote:

> I don’t know if it’s some recent change in the Guix behavior, but I
> noticed that I’m getting no utf-8 locales in a container. I discovered
> it while reading a utf-8 csv file using readr::read_csv().

Could you provide a minimalist example?


> Outside of a container, I can do this:
>
>    ~$ echo $LC_ALL
>
>    ~$ LC_ALL="en_US.utf8"
>    ~$ echo $LC_ALL
>    en_US.utf8

On my Debian machine, outside the container I get:

--8<---------------cut here---------------start------------->8---
$ LC_ALL="en_US.utf8"
bash: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8)
--8<---------------cut here---------------end--------------->8---


> But inside:
>
>    ~$ guix environment -C --pure
>    ~ [env]$ echo $LC_ALL
>
>    ~ [env]$ LC_ALL="en_US.utf8"
>    sh: warning: setlocale: LC_ALL: cannot change locale (en_US.utf8): No such 
> file or directory
>    ~ [env]$ exit
>    exit

I get that outside the container. It means that you did something
outside you are not doing inside.



> Similarly as in the bug #39665, a solution, inspired by [1], comes with
> a hack:
>
>    ~ [env]$ export GUIX_LOCPATH=/gnu/store/$(ls -F /gnu/store | grep 
> glibc-utf8-locales.*/ | tail -n 1)lib/locale
>    ~ [env]$ LC_ALL=en_US.utf8

I am not convinced by the hack of bug#39665 [1].

[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39665#8


> Are locales intentionally set to “C” in a container by default (or are
> they unset, perhaps)? I guess so, and consequently, I’m not treating
> this as a bug.

I do not know.



All the best,
simon