Dear, On Thu, 20 Feb 2020 at 16:42, Wiktor Żelazny <w...@freeshell.de> 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