From: Zefram <zefram@fysh.org>
To: 22902@debbugs.gnu.org
Subject: bug#22902: GUILE_INSTALL_LOCALE not equivalent to setlocale
Date: Fri, 4 Mar 2016 03:34:52 +0000 [thread overview]
Message-ID: <20160304033452.GB1318@fysh.org> (raw)
The documentation claims that setting GUILE_INSTALL_LOCALE=1 in the
environment is equivalent to calling (setlocale LC_ALL "") at startup.
Actually there is at least one difference: calling setlocale causes ports
(both primordial and later-opened) to be initially configured for the
locale's nominal character encoding, but setting the environment variable
does not. Setting the environment variable leaves the port encoding at
#f, functioning as ISO-8859-1, just as if locale had not been invoked
at all. I do see some effects from setting the environment variable,
specifically message strings affecting strftime.
$ echo -n $'L\xc3\xa9on' | LANG=de_DE.UTF-8 guile-2.0 -c '(write (strftime "%c" (gmtime 1000000000))) (newline) (write (port-encoding (current-input-port))) (newline) (write (map char->integer (let r ((l '\''())) (let ((c (read-char (current-input-port)))) (if (eof-object? c) (reverse l) (r (cons c l))))))) (newline)'
"Sun Sep 9 01:46:40 2001"
#f
(76 195 169 111 110)
$ echo -n $'L\xc3\xa9on' | GUILE_INSTALL_LOCALE=1 LANG=de_DE.UTF-8 guile-2.0 -c '(write (strftime "%c" (gmtime 1000000000))) (newline) (write (port-encoding (current-input-port))) (newline) (write (map char->integer (let r ((l '\''())) (let ((c (read-char (current-input-port)))) (if (eof-object? c) (reverse l) (r (cons c l))))))) (newline)'
"So 09 Sep 2001 01:46:40 GMT"
#f
(76 195 169 111 110)
$ echo -n $'L\xc3\xa9on' | LANG=de_DE.UTF-8 guile-2.0 -c '(setlocale LC_ALL "") (write (strftime "%c" (gmtime 1000000000))) (newline) (write (port-encoding (current-input-port))) (newline) (write (map char->integer (let r ((l '\''())) (let ((c (read-char (current-input-port)))) (if (eof-object? c) (reverse l) (r (cons c l))))))) (newline)'
"So 09 Sep 2001 01:46:40 GMT"
"UTF-8"
(76 233 111 110)
In case anyone trawls the archives later investigating the usage of
GUILE_INSTALL_LOCALE: I am not attempting to use it myself, despite the
scenario implied by the above test cases. I think it's a bloody stupid
mechanism, imposing on the program something that needs to be under the
program's control, and which previously was. I'm actually investigating
how to make programs cope with the unpredictable situation caused by
this mechanism with the unpredictable environment setting.
-zefram
next reply other threads:[~2016-03-04 3:34 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-04 3:34 Zefram [this message]
2016-06-20 16:16 ` bug#22902: GUILE_INSTALL_LOCALE not equivalent to setlocale Andy Wingo
2016-08-07 21:53 ` Andy Wingo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160304033452.GB1318@fysh.org \
--to=zefram@fysh.org \
--cc=22902@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).