LinuxQuestions.org
Visit Jeremy's Blog.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 12-09-2017, 12:55 PM   #1
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,642

Rep: Reputation: Disabled
Slackware-current - LANG variable


On my Slackware64-current system the default LANG variable is exported in '/etc/profile.d/lang.sh'.
Code:
export LANG=en_US.UTF-8
But then lets consider this test case.
Code:
touch test
strace cat test 2>&1 | grep ENOENT
Which prints the following.
Code:
open("/usr/lib64/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/locale/en_US.UTF-8/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/locale/en_US.UTF-8/LC_MEASUREMENT", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/locale/en_US.UTF-8/LC_TELEPHONE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/locale/en_US.UTF-8/LC_ADDRESS", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/locale/en_US.UTF-8/LC_NAME", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/locale/en_US.UTF-8/LC_PAPER", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/locale/en_US.UTF-8/LC_MESSAGES", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/locale/en_US.UTF-8/LC_MONETARY", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/locale/en_US.UTF-8/LC_TIME", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/locale/en_US.UTF-8/LC_NUMERIC", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/locale/en_US.UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
Now if I change the LANG variable and repeat the test.
Code:
export LANG=en_US.utf8
Code:
open("/usr/lib64/locale/locale-archive", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
The reason for this seems to be that glibc does not provide those files, but does have.
Code:
usr/lib/locale/en_US.utf8/
usr/lib/locale/en_US.utf8/LC_ADDRESS
usr/lib/locale/en_US.utf8/LC_COLLATE
usr/lib/locale/en_US.utf8/LC_CTYPE
usr/lib/locale/en_US.utf8/LC_IDENTIFICATION
usr/lib/locale/en_US.utf8/LC_MEASUREMENT
usr/lib/locale/en_US.utf8/LC_MESSAGES/
usr/lib/locale/en_US.utf8/LC_MESSAGES/SYS_LC_MESSAGES
usr/lib/locale/en_US.utf8/LC_MONETARY
usr/lib/locale/en_US.utf8/LC_NAME
usr/lib/locale/en_US.utf8/LC_NUMERIC
usr/lib/locale/en_US.utf8/LC_PAPER
usr/lib/locale/en_US.utf8/LC_TELEPHONE
usr/lib/locale/en_US.utf8/LC_TIME
This makes me wonder, which one is correct? If the default is correct then maybe glibc is installing these files to the wrong place?
 
Old 12-09-2017, 12:59 PM   #2
Darth Vader
Senior Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 2,727

Rep: Reputation: 1236Reputation: 1236Reputation: 1236Reputation: 1236Reputation: 1236Reputation: 1236Reputation: 1236Reputation: 1236Reputation: 1236
I use in the latest -current x86_64

Code:
export LANG=en_US.UTF-8
Everything works perfect.
 
Old 12-09-2017, 02:08 PM   #3
Petri Kaukasoina
Member
 
Registered: Mar 2007
Posts: 405

Rep: Reputation: 257Reputation: 257Reputation: 257
Quote:
Originally Posted by orbea View Post
Code:
touch test
strace cat test 2>&1 | grep ENOENT
Why don't you look at the successful open()s, too:

Code:
strace -e open cat test
Both en_US.UTF-8 and en_US.utf8 work.
 
1 members found this post helpful.
Old 12-09-2017, 02:39 PM   #4
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 8,861

Rep: Reputation: Disabled
POSIX says:
Quote:
[XSI] [Option Start] If the locale value has the form:

language[_territory][.codeset]

it refers to an implementation-provided locale, where settings of language, territory, and codeset are implementation-defined.
In our case this is implemented using glibc, and "setlocale -a" only output the lower case form, so that's what I use:
Code:
didier[~]$ echo $LANG
fr_FR.utf8
However glibc is lenient enough to accept other forms
Code:
didier[~]$ LANG=fr_FR.utf8 locale -k charmap
charmap="UTF-8"
didier[~]$ LANG=fr_FR.UTF8 locale -k charmap
charmap="UTF-8"
didier[~]$ LANG=fr_FR.UTF-8 locale -k charmap
charmap="UTF-8"
didier[~]$
Probably not using "utf8" is a little more costly, if that matters.

Last edited by Didier Spaier; 12-09-2017 at 02:43 PM.
 
2 members found this post helpful.
Old 12-09-2017, 02:53 PM   #5
orbea
Senior Member
 
Registered: Feb 2015
Distribution: Slackware64-current
Posts: 1,642

Original Poster
Rep: Reputation: Disabled
Thanks, that helps explain it a bit.

So Slackware switching from UTF-8 to utf8 would be the technically correct behavior? I also agree it probably does not matter much, but it does make strace output far more noisy than it needs to be. This makes me wonder why its currently UTF-8 instead?
 
Old 12-09-2017, 03:03 PM   #6
Didier Spaier
LQ Addict
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slint64-14.2.1.2 on Lenovo Thinkpad W520
Posts: 8,861

Rep: Reputation: Disabled
I think that using utf8 as codeset is better, yes.

Maybe it is UTF-8 in lang.sh because at some point there have been a confusion between the charmap and the codeset, not sure about that.

Not something that needs a fix before the end of the day, anyway

Last edited by Didier Spaier; 12-09-2017 at 03:05 PM.
 
Old 12-09-2017, 04:40 PM   #7
GazL
LQ Guru
 
Registered: May 2008
Posts: 5,017
Blog Entries: 16

Rep: Reputation: 2617Reputation: 2617Reputation: 2617Reputation: 2617Reputation: 2617Reputation: 2617Reputation: 2617Reputation: 2617Reputation: 2617Reputation: 2617Reputation: 2617
If you make up a locale name you can clearly see the fallback mechanism at work:
Code:
open("/usr/lib64/locale/en_GB.WIBBLE-4/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/locale/en_GB.wibble4/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib64/locale/en_GB/LC_IDENTIFICATION", O_RDONLY|O_CLOEXEC) = 3
First it looks for the file as specified, then with the CODESET part converted to lowercase and with the hyphen removed, then finally only the base name without the CODESET portion.

The interesting bit is that LANG=en_GB.WIBBLE-4 will result in a ANSI_X3.4-1968 codeset being used despite LANG=en_GB resuting in ISO-8859-1.

IMO it seems more reliable to not rely on the fallback mechanism and use the locale names as defined and returned by locale -a. Thus *.utf8 are the more correct values.

Of course, all this confusion could be avoided by defining the locales with names all ending in *.UTF-8 instead of *.utf8, and I think some distro do that.
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] $LANG per user doesn't obey the global $LANG set in /etc/profile.d/lang.sh me_h Slackware 23 11-20-2016 07:28 AM
Slackware 13.37 doesn't consider setting of LANG in /etc/profile.d/lang.sh after 'su' Didier Spaier Slackware 5 12-14-2013 02:24 PM
Permanently Set Environment Variable LANG Mistro116@yahoo.com Red Hat 1 06-12-2008 08:11 PM
Environmant variable LANG estod Slackware 1 02-24-2006 07:53 PM
Setting of LANG variable r_213 Linux - General 7 01-06-2005 12:46 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 05:40 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration