[blfs-dev] Policy on locale for building ? (ticket #4745)

Bruce Dubbs bruce.dubbs at gmail.com
Sat Mar 1 14:05:15 PST 2014


Ken Moffat wrote:
> On Sat, Mar 01, 2014 at 03:29:08PM -0600, Bruce Dubbs wrote:
>> Ken Moffat wrote:
> [ snipped ]
>>
>> I have a problem with en_US.UTF-8.  I generally do not have any LC_
>> variable set and even have
>>
>> alias ls='LC_ALL=C ls --color=auto'
>>
>> because I once was running into a problem with ls ignoring case when
>> sorting.
>>
>> If I do 'LC_ALL=en_US.UTF-8 man man', I get things like below.
>>
>> ... [--no-justifiâ
>> <80><90>
>>
>> without, it gives the expected
>>
>> ... [--no-justifi-
>>
>>     -- Bruce
>   Odd.  I prefer to see case-insensitive sorting, but I haven't
> noticed that sort of problem recently in 'man'.  At the moment, both
> of the --no-justification matches in that manpage look fine with
> LC_ALL and LANG both set to en_GB.UTF-8.  I have seen that sort of
> problem occasionally in the past, I think it was on some av
> package(s) - I don't think I've looked at 'man man' in years.
>
>   Do you perhaps have any LESSCHARSET or similar variables set ?

Yes.

LESS=-MX
LESSCHARSET=latin1

With LC_ALL=en_US.UTF-8 LESSCHARSET= man man, I still get

... [--no-justifiâ

but without the <80><90>.

With LC_ALL=en_GB.UTF-8, all is as it should be.

>   Going back to gegl, do you think a note along the lines of "If you
> have installed ruby, and are building in a non-UTF-8 locale such as
> 'C', you will need to use a UTF-8 environment for compiling this
> package, for example by passing LC_ALL=en_US.UTF-8 to configure."
> would hurt ?

What about just adding the LC_ALL variable unconditionally?  It 
shouldn't hurt anything.

   -- Bruce





More information about the blfs-dev mailing list