Re: Filename encoding

[Chris Vine]

On Wed, 15 Jan 2014 13:14:39 -0500
Mark H Weaver <address@hidden> wrote:
> Chris Vine <address@hidden> writes:
> 
> > A number of guile's scheme procedures look-up or reference files on
> > a file system (open-file, load and so forth).
> >
> > How does guile translate filenames from its internal string
> > representation (ISO-8859-1/UTF-32) to narrow string filename
> > encoding when looking up the file?  Does it assume filenames are in
> > locale encoding (not particularly safe on networked file systems)
> > or does it provide a fluid for this?  (glib caters for this with the
> > G_FILENAME_ENCODING environmental variable.)
> 
> It assumes filenames are in locale encoding.  Ditto for virtually
> everything that interfaces with POSIX-style byte strings, including
> environment variables, command-line arguments, etc.  Encoding errors
> will raise exceptions by default.
> 
> My hope is that this will become less of an issue over time, as
> systems increasingly standardize on UTF-8.  I see no other good
> solution.
> 
> Thoughts?

POSIX system calls are encoding agnostic.  The filename is just a series
of bytes terminating with a NUL character.  All guile needs to know is
what encoding the person creating the filesystem has adopted in naming
files and which it needs to map to. So far as filenames are concerned,
this seems to me to be something for which a fluid would be just the
thing - it could default to the locale encoding but a user could set it
to something else.  I suppose command lines and environmental variables
are less problematic because they are usually local to a particular
machine, although that may not necessarily be so true these days for
command lines.

Fluids would have a substantial advantage over glib's approach of an
environmental variable.  Fluids can be thread safe, environmental
variables are not.  (Incidentally, with glib you can set the
environmental variable G_BROKEN_FILENAMES instead of G_FILENAME_ENCODING
which will cause the glib file functions to use locale encoding, which
I guess expresses their view on the issue.  However, their solution of
using environmental variables is not ideal.)

Chris