Re: cygpath and star character

[Corinna Vinschen <corinna-cygwin@cygwin.com>]

On Jul 14 15:26, Ken Brown via Cygwin wrote:
> On 7/14/2021 4:10 AM, Tomas Jura via Cygwin wrote:
> > Hi
> > 
> > I found a strange behaviour of the program cygpath program
> > 
> > 0 >cygpath -w "./*/*"           <--- IMHO wrong output
> >   \
> > 
> > 0 >cygpath -w "./*/*"  | od -a                   <--- a detailed dump
> > 0000000   o nul   *   \   o nul   *  nl
> > 0000010
> 
> What you're seeing here is a consequence of the way Cygwin handles valid
> POSIX file names that contain characters (like '*') that are not allowed in
> Windows file names.  See "Forbidden characters in filenames" at
> 
>   https://cygwin.com/cygwin-ug-net/using-specialnames.html
> 
> Internally, Cygwin converts "./*/*" to the wide char string L"*\*" with '*'
> replaced by 0xf02a.  This then gets converted to the multibyte sequence in
> your "detailed dump", which is not quite detailed enough:
> 
> $ cygpath -w "./*/*"  | od -b
> 0000000 357 200 252 134 357 200 252 012
> 0000010
> 
> I tend to agree that this is not desirable behavior.  I doubt if users of
> 'cygpath -w' expect to get a result that contains transformed forbidden
> characters.  But maybe there's a use case for this that I'm missing.
> Corinna?

The purpose of cygpath is to convert paths between Cygwin and Windows,
so that you can access the same file in both worlds.  The '*' character
is a valid character in Cygwin, but the created file will have a unicode
0xf02a in its place.  If cygpath doesn't convert the path accordingly,
accessing the file from Windows via the converted path would fail.

> > 0 >cygpath -wp "./*/*"         <-- but this works as expected
> > *\*
> > 
> > Is this bug or expected behavior ?
> 
> It looks to me like a bug that 'cygpath -w' and 'cygpath -wp' give different
> results on a path that doesn't contain a colon.

Yeah, that's not quite right.  Historically, the conversion of path
lists is performed on multibyte paths, not on wide char paths.  This
has never been changed, and that results in special characters getting
lost.  So in fact, the behaviour in -p is wrong for those chars invalid
in Windows and only valid for POSIX paths.


Corinna