On Tue, 22 Dec 2015 03:14:18 +0200 Marko Rauhamaa <ma...@pacujo.net> wrote: > Chris Vine <ch...@cvine.freeserve.co.uk>: > > > 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
