[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Filename encoding
From: |
Eli Zaretskii |
Subject: |
Re: Filename encoding |
Date: |
Thu, 16 Jan 2014 05:52:09 +0200 |
> Date: Wed, 15 Jan 2014 21:42:57 +0000
> From: Chris Vine <address@hidden>
> Cc: address@hidden, address@hidden
>
> I am not sure what you mean, as I am not talking about internal use.
Then I probably didn't understand why you mentioned the external
encoding. How is that relevant to the issue at hand?
I'm saying that Guile does needs to know how to convert a file name
when it needs to pass it to library functions and system calls. So
The POSIX system calls may be "encoding agnostic", but Guile simply
cannot be.
> As it happens (although this is beside the point) using a byte value or
> sequence in a filename which the operating system reserves as the '/'
> character, for a purpose other than designating a pathname, or a NUL
> character for designating anything other than end of filename, is not
> POSIX compliant and will not work on any operating system I know of,
> including windows.
Windows is not Posix-compliant, so all bets are off. As a matter of
fact, there _are_ DBCS codepages where the second byte can be '\'.
- Filename encoding, Chris Vine, 2014/01/15
- Re: Filename encoding, Mark H Weaver, 2014/01/15
- Re: Filename encoding, Chris Vine, 2014/01/15
- Re: Filename encoding, Eli Zaretskii, 2014/01/15
- Re: Filename encoding, Ludovic Courtès, 2014/01/15
- Re: Filename encoding, Eli Zaretskii, 2014/01/15
- Re: Filename encoding, Ludovic Courtès, 2014/01/16
- Re: Filename encoding, John Darrington, 2014/01/16
- Re: Filename encoding, Eli Zaretskii, 2014/01/16
- Re: Filename encoding, Eli Zaretskii, 2014/01/16
- Re: Filename encoding, Mark H Weaver, 2014/01/16