Re: Accessing the environment's locale encoding settings

[Mike Gran]

>From: Ludovic Courtès <address@hidden>
>>Bruno Haible <address@hidden> skribis:
>
>> No, I'm suggesting to let the Scheme code know that is it using the user's
>> locale.
>>
>> Yes, this is a backward-incompatible change, so probably you won't want to
>> do it on the guile 2.0.x branch, and you will want to advertise it in the
>> release notes or NEWS file.
>
>I’m now convinced that an implicit setlocale(LC_ALL, "") is the right
>thing for ‘master’.
>
>For 2.0, though, this brings us back to the hack I proposed at the
>beginning of this thread, namely trying to honor LC_CTYPE without
>actually calling setlocale, so that command-line arguments are suitably
>converted.

I probably shouldn't express an opinion on this, since my SLOC count is so
low these days, but, I'll do it anyway. ;-)
 
As I am snarkily wont to say, everyone wants Unicode but no one really uses
it.  It you were to make that change in 2.0.x, I can almost guarantee that
no one will be adversely affected.  2.0.x programs that are already trying to
use locale will just have a redundant call to setlocale. 2.0.x programs that
ignore locale are de facto C locale anyway.  The scripts that would be at risk
are those that try to read binary data as string input instead of binary input.
 
Here's a suggestion.  One could add an option to the guile interpreter's command
line args (--locale=ARG perhaps) that has the effect of calling
setlocale(LC_ALL,"ARG") first thing.  If --locale is called with no ARG
specified, it would call to setlocale(LC_ALL, "").
 
That way, people could start future-proofing their code now by adding
--locale or --locale=C to the top of their scripts.  For now, the default can
be, in effect, --locale=C and for 2.2 it can be --locale.
 
That would slightly complicate getopt processing, since you'd have to scan for
the --locale before processing other getopt arguments.
 
-Mike