On Apr 23 08:43, David Macek wrote: > On 21. 4. 2018 17:38, Brian Inglis wrote: > > See my other post in this thread where strace shows @ handling is not > > involved, > > as the script directory and name are normalized and converted to a win32 > > path > > correctly, but child_info_spawn::worker does not appear to quote args with > > spaces (or apostrophes) when building the command line, despite the comment > > near > > the top of the function. > > Do you have a test case for this? In my testing, paths with spaces (like 'x > y' instead of '@ x') work just fine.
Brian has a point though. It's not a space *in* a filename, it's a *trailing* space. And that points to the cause of the problem: Paths with trailing spaces are invalid DOS paths. Try this: bash$ mkdir "x " bash$ cmd C:\...>cd "x " cd "x " The system cannot find the path specified. The problem is not exactly in Cygwin, it's the good old fact that Win32 tools using the WIn32 file API just can't accfess the file because they don't see it. The Win32 API simply deletes trailing spaces from filenames, in and out. Cygwin doesn't suffer this problem because it uses the underlying NT API. https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-specialchars The only workaround from Cygwin's side would be to convert 0x20 spaces to 0xf020 characters as the other invalid chars as outlined in the above URL. However, this would only be ok for trailing spaces, given that leading or in-between spaces are perfectly valid. Sounds kind of error prone. IMHO, better leave it as is and tell the user. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
signature.asc
Description: PGP signature
