public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* cygpath and star character
@ 2021-07-14  8:10 Tomas Jura
  2021-07-14 19:26 ` Ken Brown
  0 siblings, 1 reply; 5+ messages in thread
From: Tomas Jura @ 2021-07-14  8:10 UTC (permalink / raw)
  To: cygwin

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

0 >cygpath -wp "./*/*"         <-- but this works as expected
*\*

Is this bug or expected behavior ?

Pls, answer to me in To:, I'm not a permanent member of the cygwin email 
list.

I found it during assembly of the Java CLASSPATH variable, which may 
contain the "*" character at the end to cover all .jar in the specified 
directory.

Tomas


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: cygpath and star character
  2021-07-14  8:10 cygpath and star character Tomas Jura
@ 2021-07-14 19:26 ` Ken Brown
  2021-07-14 23:07   ` Tomas Jura
  2021-07-15  9:11   ` Corinna Vinschen
  0 siblings, 2 replies; 5+ messages in thread
From: Ken Brown @ 2021-07-14 19:26 UTC (permalink / raw)
  To: Tomas Jura, cygwin

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?

> 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.

Ken

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: cygpath and star character
  2021-07-14 19:26 ` Ken Brown
@ 2021-07-14 23:07   ` Tomas Jura
  2021-07-15  6:18     ` Sam Edge
  2021-07-15  9:11   ` Corinna Vinschen
  1 sibling, 1 reply; 5+ messages in thread
From: Tomas Jura @ 2021-07-14 23:07 UTC (permalink / raw)
  To: cygwin

Hi

My use case is building the CLASSPATH environment variable for java. Like:

export CLASSPATH="${CLASSPATH}${PATH_SEPARATOR}$(cygpath -w 
'my/java/jar/directory/*' )"

CLASSPATH can contain the star character at the end on Windows. Example 
C:\Apps\java\lib\* , which means something different then just 
C:\Apps\java\lib, ie. the star is necessary there.

Tomas

  14. 07. 21 v 21:26 Ken Brown 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?
>
>> 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.
>
> Ken



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: cygpath and star character
  2021-07-14 23:07   ` Tomas Jura
@ 2021-07-15  6:18     ` Sam Edge
  0 siblings, 0 replies; 5+ messages in thread
From: Sam Edge @ 2021-07-15  6:18 UTC (permalink / raw)
  To: cygwin

On 15/07/2021 00:07, Tomas Jura via Cygwin wrote:

> Hi
>
> My use case is building the CLASSPATH environment variable for java.
> Like:
>
> export CLASSPATH="${CLASSPATH}${PATH_SEPARATOR}$(cygpath -w
> 'my/java/jar/directory/*' )"
>
> CLASSPATH can contain the star character at the end on Windows.
> Example C:\Apps\java\lib\* , which means something different then just
> C:\Apps\java\lib, ie. the star is necessary there.
>
> Tomas
>
>

So do:

export CLASSPATH="${CLASSPATH}${PATH_SEPARATOR}$(cygpath -w
'my/java/jar/directory')\*"

If you pass the asterisk to cygpath it will naturally consider it to be
a character in a pathname and give you the equivalent Windows path that
Cygwin would construct using the open() syscall. This is cygpath's
purpose, after all!

--
Sam Edge


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: cygpath and star character
  2021-07-14 19:26 ` Ken Brown
  2021-07-14 23:07   ` Tomas Jura
@ 2021-07-15  9:11   ` Corinna Vinschen
  1 sibling, 0 replies; 5+ messages in thread
From: Corinna Vinschen @ 2021-07-15  9:11 UTC (permalink / raw)
  To: cygwin

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-07-15  9:11 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-14  8:10 cygpath and star character Tomas Jura
2021-07-14 19:26 ` Ken Brown
2021-07-14 23:07   ` Tomas Jura
2021-07-15  6:18     ` Sam Edge
2021-07-15  9:11   ` Corinna Vinschen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).