Re: Filenames with Win32 special characters (or: Interix filename compatibility)

[Corinna Vinschen <corinna-cygwin at cygwin dot com>]

On Mar 12 12:21, Brian Dessent wrote:
> Corinna Vinschen wrote:
> 
> > > What about this scheme for special DOS chars in non-managed mounts?  Do
> > > you expect to access these files, which just didn't exist before, using
> > > a native ANSI tool?
> 
> No, I don't have any expectation of anything working there, so the
> unicode munging is clearly a win-win there.
> 
> > Btw., this access problem potentially also happens to you in Cygwin.
> > Given you run a shell in codepage:ansi or codepage:oem mode, and in
> > another codepage:utf8 session you created a file with characters not
> > available in your ANSI or OEM codepage.  If you try to access this file
> > in the ansi or oem session, you'll get a ENOENT error.  There's nothing
> > you can do about that, as soon as you use 8-bit codepages.  That's one
> > of the reasons to use wide char file access functions.  It's not all
> > about long path names, it's also about being able to access utf chars,
> > even if that might still be buggy right now.
> 
> Does that mean you're in favor of making codepage:utf8 the default if
> not specified in the near future?

Actually I think we should get to the point at which we don't use
ANSI functions at all, except where it doesn't hurt.  This would remove
the reason to set the codepage at all.  The conversion should depend
on the values of $LANG or $LC_CTYPE only.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat