[Top][All Lists]

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

Re: Running script from directory with UTF-8 characters

From: Chris Vine
Subject: Re: Running script from directory with UTF-8 characters
Date: Tue, 22 Dec 2015 14:21:25 +0000

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.


reply via email to

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