It seems that guile-2.0 applies locale encoding and decoding to pathnames
being used in system calls. This radically breaks file access anywhere
that the locale's character encoding is anything other than a simple
8-bit encoding such as ISO-8859-1. For example, in the default C locale
with its no
I wrote:
>My comments about resolution in bug#20822 "environment mangled by locale"
>mostly apply here too,
The revised comments that I have just made on that ticket also apply
here. Short version: "absence of setlocale" isn't a useful criterion,
so explicit control of encoding will be necessary.
I wrote:
>There's an obvious parallel with reading data from an input port.
>If setlocale is called, then input is by default decoded according
>to locale, including the very lossy ASCII decode for C/POSIX. But if
>setlocale has not been called, then input is by default decoded according
>to ISO-8
Additional information: setlocale's side effect on primordial ports
happens even if the port's encoding has been individually set using
set-port-encoding!. This means that to maintain a specific encoding on
these ports (other than the locale's nominal encoding, which is likely to
not be binary com
A call to setlocale with no second argument is documented to be
a read-only operation, querying the current locale configuration.
In fact it has a side effect of setting the encoding on primordial ports:
$ guile-2.0 -c '(write (port-encoding (current-input-port))) (newline)
(setlocale LC_TIME) (w
GUILE_INSTALL_LOCALE=1 breaks some of the robustness of non-locale-using
programs, marring their stderr output if the environment's locale settings
are faulty.
Suppose you have a program written in Guile Scheme that doesn't use any
locale facilities. To be portable to the GUILE_INSTALL_LOCALE=1 s
