GNU bug report logs -
#22902
GUILE_INSTALL_LOCALE not equivalent to setlocale
Previous Next
Reported by: Zefram <zefram <at> fysh.org>
Date: Fri, 4 Mar 2016 03:36:01 UTC
Severity: normal
Done: Andy Wingo <wingo <at> pobox.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 22902 in the body.
You can then email your comments to 22902 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guile <at> gnu.org
:
bug#22902
; Package
guile
.
(Fri, 04 Mar 2016 03:36:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Zefram <zefram <at> fysh.org>
:
New bug report received and forwarded. Copy sent to
bug-guile <at> gnu.org
.
(Fri, 04 Mar 2016 03:36:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-guile <at> gnu.org
:
bug#22902
; Package
guile
.
(Mon, 20 Jun 2016 16:17:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 22902 <at> debbugs.gnu.org (full text, mbox):
On Fri 04 Mar 2016 04:34, Zefram <zefram <at> fysh.org> writes:
> 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.
Indeed! Thank you for this analysis; I was wondering why I was getting
terrible backtraces in Guile master.
Andy
Reply sent
to
Andy Wingo <wingo <at> pobox.com>
:
You have taken responsibility.
(Sun, 07 Aug 2016 21:54:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Zefram <zefram <at> fysh.org>
:
bug acknowledged by developer.
(Sun, 07 Aug 2016 21:54:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 22902-done <at> debbugs.gnu.org (full text, mbox):
On Fri 04 Mar 2016 04:34, Zefram <zefram <at> fysh.org> writes:
> 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.
I believe this is fixed in both 2.0 and master. Thanks for the report.
Andy
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Mon, 05 Sep 2016 11:24:03 GMT)
Full text and
rfc822 format available.
This bug report was last modified 8 years and 285 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.