emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[debbugs-tracker] bug#22902: closed (GUILE_INSTALL_LOCALE not equivalent


From: GNU bug Tracking System
Subject: [debbugs-tracker] bug#22902: closed (GUILE_INSTALL_LOCALE not equivalent to setlocale)
Date: Sun, 07 Aug 2016 21:54:02 +0000

Your message dated Sun, 07 Aug 2016 23:53:04 +0200
with message-id <address@hidden>
and subject line Re: bug#22902: GUILE_INSTALL_LOCALE not equivalent to setlocale
has caused the debbugs.gnu.org bug report #22902,
regarding GUILE_INSTALL_LOCALE not equivalent to setlocale
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden)


-- 
22902: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=22902
GNU Bug Tracking System
Contact address@hidden with problems
--- Begin Message --- Subject: GUILE_INSTALL_LOCALE not equivalent to setlocale Date: Fri, 4 Mar 2016 03:34:52 +0000
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



--- End Message ---
--- Begin Message --- Subject: Re: bug#22902: GUILE_INSTALL_LOCALE not equivalent to setlocale Date: Sun, 07 Aug 2016 23:53:04 +0200 User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
On Fri 04 Mar 2016 04:34, Zefram <address@hidden> 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


--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]