I'm stumped: I've had LANG=en_GB.UTF8 in /etc/locale.conf ever since the switch to systemd, but in the last few days since my previous reboot, something's changed (maybe systemd 216?) and now I find that, even though /etc/locale.conf still contains en_GB, I get:
# echo $LANG en_US.UTF8
This is almost certainly related to why I'm getting messed up character encoding in Konsole. In particular, tmux fails to render dividing lines properly, showing accented 'a' characters instead, and similar things happen in Vim.
Is there some additional configuration I need beyond /etc/locale.conf now? I've checked locale.gen and rerun locale-gen without any effect. I've also tried rerunning mkinitpio for good measure.
Any ideas?
Paul
2014-10-31 12:14 GMT-02:00 Paul Gideon Dann pdgiddie@gmail.com:
Is there some additional configuration I need beyond /etc/locale.conf now? I've checked locale.gen and rerun locale-gen without any effect. I've also tried rerunning mkinitpio for good measure.
Any ideas?
Paul
localectl list-locales localectl set-locale en_GB.utf8
On 31 October 2014 14:20, Mateus Rodrigues Costa charles.costar@gmail.com wrote:
2014-10-31 12:14 GMT-02:00 Paul Gideon Dann pdgiddie@gmail.com:
Is there some additional configuration I need beyond /etc/locale.conf
now?
I've checked locale.gen and rerun locale-gen without any effect. I've
also
tried rerunning mkinitpio for good measure.
Any ideas?
Paul
localectl list-locales localectl set-locale en_GB.utf8
Hmm well that helped a little:
# sudo localectl list-locales en_GB en_GB.iso88591 en_GB.utf8
# sudo localectl set-locale en_GB.utf8 Failed to issue method call: Invalid Locale data.
Could this be a corrupted file? (Feasible, as we did have a power cut.) I tried reinstalling glibc, but that didn't help.
Paul
2014-10-31 13:34 GMT-02:00 Paul Gideon Dann pdgiddie@gmail.com:
# sudo localectl set-locale en_GB.utf8 Failed to issue method call: Invalid Locale data.
Could this be a corrupted file? (Feasible, as we did have a power cut.) I tried reinstalling glibc, but that didn't help.
Paul
localectl set-locale LANG=en_GB.utf8
On 31 October 2014 15:42, Mateus Rodrigues Costa charles.costar@gmail.com wrote:
2014-10-31 13:34 GMT-02:00 Paul Gideon Dann pdgiddie@gmail.com:
# sudo localectl set-locale en_GB.utf8 Failed to issue method call: Invalid Locale data.
Could this be a corrupted file? (Feasible, as we did have a power cut.) I tried reinstalling glibc, but that didn't help.
Paul
localectl set-locale LANG=en_GB.utf8
# sudo localectl set-locale LANG=en_GB.utf8 # echo $LANG en_US.UTF-8 # sudo localectl System Locale: LANG=en-GB.utf8 VC Keymap: dvorak X11 Layout: n/a
I tried a new login session too in a fresh VT, and the LANG environment variable is still en_US.UTF-8.
Paul
Maybe you have the lang set somewhere in your shell configfile. Have you tried with a new user?
On 3 November 2014 09:24, Jesse Jaara jesse.jaara@gmail.com wrote:
Maybe you have the lang set somewhere in your shell configfile. Have you tried with a new user?
Hmm; yeah, getting somewhere now. I haven't made any modifications to my shell config for a while, but I did find this (I use zprezto):
if [[ -z "LANG" ]]; then export LANG='en_US.UTF-8' fi
I've commented that out, and I get en_GB.UTF-8 now (which is odd in itself), but Tmux and Vim still render incorrectly: dividing lines are accented characters. The Linux built-in console renders some lines correctly, but some angled lines in Vim are rendered as blocks, so it doesn't seem to be a Konsole thing.
When I try to invoke "man", I get:
man: can't set the locale; make sure $LC_* and $LANG are correct.
I don't have any LC_ variable set manually, but I didn't think I needed to...
Also:
# locale -a locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_COLLATE to default locale: No such file or directory C POSIX en_GB en_GB.iso88591 en_GB.utf8
I've done:
# pacman -Qqkk | grep GB
...but that returns nothing.
Any more ideas?
Paul
On 3 November 2014 10:00, Paul Gideon Dann pdgiddie@gmail.com wrote:
Any more ideas?
Oh BTW, I've also tried bypassing my ZSH config entirely, but no difference.
Paul
Em Mon Nov 03 2014 at 08:00:43, Paul Gideon Dann pdgiddie@gmail.com escreveu:
On 3 November 2014 09:24, Jesse Jaara jesse.jaara@gmail.com wrote:
Also:
# locale -a locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_COLLATE to default locale: No such file or directory C POSIX en_GB en_GB.iso88591 en_GB.utf8
Paul
Shouldn't you also have the en_US locales available? Just in case? Also, why enable the ISO locales if you can run basically with only the UTF-8 ones?
On 3 November 2014 13:37, AIS Information info@andriesinfoserv.com wrote:
i think you may just have a typo. shouldn't it be "en_GB.UTF-8" instead of "en_GB.utf8"?
Thanks; I've tried various combinations. Mostly, I've used en_GB.UTF-8, as that matches the entry in locale.conf, and worked fine previously.
Your original message was sent in reply to a message digest. I'm replying in the actual thread in the interests of keeping the threads connected.
Paul
On 3 November 2014 11:36, Mateus Rodrigues Costa charles.costar@gmail.com wrote:
Shouldn't you also have the en_US locales available? Just in case? Also, why enable the ISO locales if you can run basically with only the UTF-8 ones?
I've tried enabling the en_US locales, and it doesn't help. I suspect the issues I'm having with console rendering is actually not directly related to the locale, as I've been able to get en_GB.UTF-8 to show up in LANG now by disabling the logic in my ZSH profile that was setting the locale because it was unset. I've no idea how it's set to en_GB.UTF-8 *after* the ZSH config runs, but that seems to be the case.
I've tried disabling the ISO locale and re-running locale-gen, but that doesn't help.
My best bet at this stage is that I have a corrupted file somewhere, but pacman -Qqkk doesn't show up anything obvious. I'd think it was an issue with a new package version, but as I'm the only one seeing this, I assume it must be a configuration / corruption issue with my specific system.
Paul
Em Mon Nov 03 2014 at 12:03:33, Paul Gideon Dann pdgiddie@gmail.com escreveu:
On 3 November 2014 11:36, Mateus Rodrigues Costa <charles.costar@gmail.com
wrote:
Shouldn't you also have the en_US locales available? Just in case? Also, why enable the ISO locales if you can run basically with only the UTF-8 ones?
I've tried enabling the en_US locales, and it doesn't help. I suspect the issues I'm having with console rendering is actually not directly related to the locale, as I've been able to get en_GB.UTF-8 to show up in LANG now by disabling the logic in my ZSH profile that was setting the locale because it was unset. I've no idea how it's set to en_GB.UTF-8 *after* the ZSH config runs, but that seems to be the case.
Paul
Any chance this helps? https://wiki.archlinux.org/index.php/Locale Also, how about setting LANG=en_GB.utf8 inside /etc/locale.conf and ~/.config/locale.conf ? Now, about the UTF-8 and utf8 difference: I am not sure if there is any, but both localectl list-locales and locale -a use "utf8" in my system.
Any chance this helps? https://wiki.archlinux.org/index.php/Locale Also, how about setting LANG=en_GB.utf8 inside /etc/locale.conf and ~/.config/locale.conf ? Now, about the UTF-8 and utf8 difference: I am not sure if there is any, but both localectl list-locales and locale -a use "utf8" in my system.
the canonical name is UTF-8 and that's the one that should be used, glibc normalizes that to lowercase and removes the dashes and underscores when it searches the archive (because of legacy iso-8859-x charsets which didn't have a clear standard how to write them down)
I don't know of programs that will use ~/.config/locale.conf. Most (if not all) Linux/glibc programs use the LANG and LC_* environment variables. So to have a working locale in your environment, you have to know how unix environment variables are inherited and from where in your case.
Also, always use just the LANG variable to set the locale, only use LC_CTYPE etc, if you want to override some part of the locale. Only ever use LC_ALL on the command line if you must make sure that some hierarchy of processes will use that locale (it overrides LANG and the other LC_ variables).
On 03-11-2014 14:03, Paul Gideon Dann wrote:
My best bet at this stage is that I have a corrupted file somewhere, but pacman -Qqkk doesn't show up anything obvious. I'd think it was an issue with a new package version, but as I'm the only one seeing this, I assume it must be a configuration / corruption issue with my specific system.
Paul
Did you check /etc/profile.d for any changed/added files that may be changing the locale?
On 3 November 2014 15:05, Mauro Santos registo.mailling@gmail.com wrote:
On 03-11-2014 14:03, Paul Gideon Dann wrote:
My best bet at this stage is that I have a corrupted file somewhere, but pacman -Qqkk doesn't show up anything obvious. I'd think it was an issue with a new package version, but as I'm the only one seeing this, I assume it must be a configuration / corruption issue with my specific system.
Paul
Did you check /etc/profile.d for any changed/added files that may be changing the locale?
-- Mauro Santos
Thanks to all for the suggestions so far. This in particular did yield something interesting:
The /etc/profile.d/locale.sh file (from the "filesystem" package) changed recently. Basically, it looks like the logic has altered a little: whereas previously it would unset LANG and source /etc/locale.conf, it now only sets LANG if it's not already set. That explains the weird interaction with my zshenv: it was supposed to fall back to en_US in zshenv, but in fact was always setting en_US, which was later forcibly reset to en_GB by /etc/profile.d/locale.sh. After the filesystem update, /etc/profile.d/locale.sh was leaving LANG as it was. I've fixed this in my .zshenv for now.
So that explains why my locale wasn't being set correctly. However, it doesn't explain why I'm seeing broken rendering of special characters in the terminal (mainly lines and other terminal graphics). This looks like it might not be directly related?
Paul
Em Mon Nov 03 2014 at 13:26:33, Paul Gideon Dann pdgiddie@gmail.com escreveu:
So that explains why my locale wasn't being set correctly. However, it doesn't explain why I'm seeing broken rendering of special characters in the terminal (mainly lines and other terminal graphics). This looks like it might not be directly related?
Paul
Are you sure the terminal is configured for UTF-8? And you are also sure you're currently using the UTF-8 locale (run locale and check the output)?
On 03-11-2014 15:26, Paul Gideon Dann wrote:
So that explains why my locale wasn't being set correctly. However, it doesn't explain why I'm seeing broken rendering of special characters in the terminal (mainly lines and other terminal graphics). This looks like it might not be directly related?
Paul
If it is terminal emulator under X I would check the font configuration, if you mean VT then /etc/vconsole.conf is the place to look at.
On the other hand, I would check what was updated around the time things started looking weird, maybe you caught a bug, or font handling changed.
I would also check other terminal emulators, preferably with different dependencies to try a rule out any bug in the dependencies.
On 3 November 2014 15:44, Mauro Santos registo.mailling@gmail.com wrote:
On 03-11-2014 15:26, Paul Gideon Dann wrote:
So that explains why my locale wasn't being set correctly. However, it doesn't explain why I'm seeing broken rendering of special characters in the terminal (mainly lines and other terminal graphics). This looks like
it
might not be directly related?
Paul
If it is terminal emulator under X I would check the font configuration, if you mean VT then /etc/vconsole.conf is the place to look at.
On the other hand, I would check what was updated around the time things started looking weird, maybe you caught a bug, or font handling changed.
I would also check other terminal emulators, preferably with different dependencies to try a rule out any bug in the dependencies.
-- Mauro Santos
I'd forgotten about this, although I mentioned it a few posts back:
# locale locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory LANG=en-GB.utf8 LC_CTYPE="en-GB.utf8" LC_NUMERIC="en-GB.utf8" LC_TIME="en-GB.utf8" LC_COLLATE="en-GB.utf8" LC_MONETARY="en-GB.utf8" LC_MESSAGES="en-GB.utf8" LC_PAPER="en-GB.utf8" LC_NAME="en-GB.utf8" LC_ADDRESS="en-GB.utf8" LC_TELEPHONE="en-GB.utf8" LC_MEASUREMENT="en-GB.utf8" LC_IDENTIFICATION="en-GB.utf8" LC_ALL=
Looks like there are still locale issues...
Paul
Em Mon Nov 03 2014 at 14:08:11, Paul Gideon Dann pdgiddie@gmail.com escreveu:
I'd forgotten about this, although I mentioned it a few posts back:
# locale locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory LANG=en-GB.utf8 LC_CTYPE="en-GB.utf8" LC_NUMERIC="en-GB.utf8" LC_TIME="en-GB.utf8" LC_COLLATE="en-GB.utf8" LC_MONETARY="en-GB.utf8" LC_MESSAGES="en-GB.utf8" LC_PAPER="en-GB.utf8" LC_NAME="en-GB.utf8" LC_ADDRESS="en-GB.utf8" LC_TELEPHONE="en-GB.utf8" LC_MEASUREMENT="en-GB.utf8" LC_IDENTIFICATION="en-GB.utf8" LC_ALL=
Looks like there are still locale issues...
Paul
Looks like it wants some unavailable locales. Is the en_US.utf8 locale available? Also shouldn't it be "en_GB" instead of "en-GB"?
In LC_* and LANG utf8 in lower case and without a minus is, from my experience illegal. Did you try using upper-case environment values?
cheers! mar77i
On 3 November 2014 16:24, Mateus Rodrigues Costa charles.costar@gmail.com wrote:
Em Mon Nov 03 2014 at 14:08:11, Paul Gideon Dann pdgiddie@gmail.com escreveu:
I'd forgotten about this, although I mentioned it a few posts back:
# locale locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or
directory
locale: Cannot set LC_ALL to default locale: No such file or directory LANG=en-GB.utf8 LC_CTYPE="en-GB.utf8" LC_NUMERIC="en-GB.utf8" LC_TIME="en-GB.utf8" LC_COLLATE="en-GB.utf8" LC_MONETARY="en-GB.utf8" LC_MESSAGES="en-GB.utf8" LC_PAPER="en-GB.utf8" LC_NAME="en-GB.utf8" LC_ADDRESS="en-GB.utf8" LC_TELEPHONE="en-GB.utf8" LC_MEASUREMENT="en-GB.utf8" LC_IDENTIFICATION="en-GB.utf8" LC_ALL=
Looks like there are still locale issues...
Paul
Looks like it wants some unavailable locales. Is the en_US.utf8 locale available? Also shouldn't it be "en_GB" instead of "en-GB"?
Yes! Right on the money. I don't know when locale became more fussy, but fixing that dash to an underscore fixes the issue with locale:
# locale LANG=en_GB.utf8 LC_CTYPE="en_GB.utf8" LC_NUMERIC="en_GB.utf8" LC_TIME="en_GB.utf8" LC_COLLATE="en_GB.utf8" LC_MONETARY="en_GB.utf8" LC_MESSAGES="en_GB.utf8" LC_PAPER="en_GB.utf8" LC_NAME="en_GB.utf8" LC_ADDRESS="en_GB.utf8" LC_TELEPHONE="en_GB.utf8" LC_MEASUREMENT="en_GB.utf8" LC_IDENTIFICATION="en_GB.utf8" LC_ALL=
...and after restarting my X session, the rendering issues have gone away.
*Thanks* everyone involved. I guess the system had been tolerating that incorrect LANG setting in /etc/locale.conf for some time, and an update finally triggered the issue. I definitely didn't touch the file, so I guess some code somewhere decided to be less tolerant. Ultimately my own fault, of course! I'm pretty embarrassed that I hadn't checked it carefully enough!
Thanks again to all!
Paul
On 03-11-2014 16:07, Paul Gideon Dann wrote:
I'd forgotten about this, although I mentioned it a few posts back:
# locale locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory LANG=en-GB.utf8 LC_CTYPE="en-GB.utf8" LC_NUMERIC="en-GB.utf8" LC_TIME="en-GB.utf8" LC_COLLATE="en-GB.utf8" LC_MONETARY="en-GB.utf8" LC_MESSAGES="en-GB.utf8" LC_PAPER="en-GB.utf8" LC_NAME="en-GB.utf8" LC_ADDRESS="en-GB.utf8" LC_TELEPHONE="en-GB.utf8" LC_MEASUREMENT="en-GB.utf8" LC_IDENTIFICATION="en-GB.utf8" LC_ALL=
Looks like there are still locale issues...
Paul
This is what I have/get:
# locale LANG=en_US.UTF-8 LC_CTYPE=en_US.UTF-8 LC_NUMERIC=en_US.UTF-8 LC_TIME=pt_PT.UTF-8 LC_COLLATE=pt_PT.UTF-8 LC_MONETARY=pt_PT.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=pt_PT.UTF-8 LC_NAME=en_US.UTF-8 LC_ADDRESS=en_US.UTF-8 LC_TELEPHONE=en_US.UTF-8 LC_MEASUREMENT=pt_PT.UTF-8 LC_IDENTIFICATION=en_US.UTF-8 LC_ALL=
I do have all of these explicitly set in /etc/locale.conf, exactly like shown on the output of locale (except LC_ALL).
As a last resort shot in the dark I would try changing en-GB.utf8 to whatever 'locale -a' outputs. The output of 'locale -a' should include the locale you want, if it doesn't then you have to double check /etc/locale.gen and rerun locale-gen.
Another shot in the dark, try with a new user and set the shell to bash, just to add another data point and dismiss anything weird going on with the shell you are using.
No more ideas here. This is most probably caused by something you might have changed, the trouble is always finding what.
Am 03.11.2014 10:21, schrieb Paul Gideon Dann:
On 31 October 2014 15:42, Mateus Rodrigues Costa charles.costar@gmail.com wrote:
2014-10-31 13:34 GMT-02:00 Paul Gideon Dann pdgiddie@gmail.com:
# sudo localectl set-locale en_GB.utf8 Failed to issue method call: Invalid Locale data.
Could this be a corrupted file? (Feasible, as we did have a power cut.) I tried reinstalling glibc, but that didn't help.
Paul
localectl set-locale LANG=en_GB.utf8
# sudo localectl set-locale LANG=en_GB.utf8 # echo $LANG en_US.UTF-8 # sudo localectl System Locale: LANG=en-GB.utf8 VC Keymap: dvorak X11 Layout: n/a
I tried a new login session too in a fresh VT, and the LANG environment variable is still en_US.UTF-8.
Paul
You have to run
# locale-gen
On 3 November 2014 09:45, Jürgen Werner jotz.csp@web.de wrote:
You have to run
# locale-gen
Jürgen, note my original post:
I've checked locale.gen and rerun locale-gen without any effect. I've
also tried rerunning mkinitpio for good measure.
Paul
Am 03.11.2014 11:03, schrieb Paul Gideon Dann:
On 3 November 2014 09:45, Jürgen Werner jotz.csp@web.de wrote:
You have to run
# locale-gen
Jürgen, note my original post:
I've checked locale.gen and rerun locale-gen without any effect. I've
also tried rerunning mkinitpio for good measure.
Paul
Well, I meant after running
sudo localectl set-locale LANG=en_GB.utf8
You didn't list that, so I thought you forgot it.
On 3 November 2014 11:03, Jürgen Werner jotz.csp@web.de wrote:
Am 03.11.2014 11:03, schrieb Paul Gideon Dann:
On 3 November 2014 09:45, Jürgen Werner jotz.csp@web.de wrote:
You have to run
# locale-gen
Jürgen, note my original post:
I've checked locale.gen and rerun locale-gen without any effect. I've
also tried rerunning mkinitpio for good measure.
Paul
Well, I meant after running
sudo localectl set-locale LANG=en_GB.utf8
You didn't list that, so I thought you forgot it.
OK, I see. I can't see why that would be necessary, but in the interest of completeness I've re-run locale-gen, and I'm afraid there was no effect.
Paul
arch-general@lists.archlinux.org