Re: Running script from directory with UTF-8 characters

[Chris Vine]

On Tue, 22 Dec 2015 03:14:18 +0200
Marko Rauhamaa <address@hidden> wrote:
> Chris Vine <address@hidden>:
> 
> > I think the problem is that calling the native 'primitive-load'
> > procedure on a filename with UTF-8 encoding with a character outside
> > the ASCII range (when the locale encoding is also UTF-8) fails to
> > work unless you call '(set-locale LC_ALL "")' in the program first.
> >
> > Of course you can't do that when passing guile a filename as a
> > program argument. It does seem like a weakness, even if not a bug.  
> 
> How can it not be a bug?
> 
> Also, Linux pathnames can contain any bytes other than NUL regardless
> of the locale (and quite often do) so I hope Guile doesn't paint
> itself too deep in the Unicode corner. Python is struggling with
> analogous issues but has been careful to at least make it possible to
> deal with bytevector pathnames and bytevector standard ports.
> 
> For example,
> 
>     scheme@(guile-user)> (opendir ".")
>     $1 = #<directory stream f7ffa0>
>     [...]
>     scheme@(guile-user)> (readdir $1)
>     $4 = "?9t\x1b["
>     scheme@(guile-user)> (open-file $4 "r")
>     ERROR: In procedure open-file:
>     ERROR: In procedure open-file: No such file or directory:
> "?9t\x1b["

You can set the locale in the REPL, if that is where you are working
from (as in your example), and then UTF-8 pathnames will work fine.

The problem about this is that although a developer might use the REPL,
and therefore maybe assume that that is what everyone else does, the end
user probably just wants to run the script by passing guile a file name
on the command line.  To that extent I agree it is a bug.  But the
response to the filing of such a bug might be that that is how it is
meant to work.

Chris