On Fri, 1 Aug 2025 15:34:16 +0000 "Old, Oliver" wrote: > > >echo-win32.exe C:\"Program Files"\ > > echo-win32.exe > > C:"Program > > Files\ > > > > Is this as you expected? > > > > >echo.exe C:\"Program Files"\ > > echo > > C:\Program Files\ > > > > This makes more sense to me. > > That is as expected. It is the way a Windows program would split the > command line. To me, it does not make sense that Cygwin programs process > the command line, which was produced by a Windows program, in a manner > which is inconsistent with how a Windows program would. > > If the sole purpose of taking a Windows command line is being able to be > called from a Windows program, how does it make sense to diverge from > Windows' parsing logic, aside from handling at-files?
So, shouldn't you be complaining abount PowerShell as well? PS C:\> .\echo-win32.exe C:\"Program Files"\ C:\echo-win32.exe C:\Program Files" PS C:\> .\echo-win32.exe a b\"c\" d a b\c\ d Moreover, you might complain about bash: $ ./echo.exe C:\Windows\System32 '"' '\' ./a C:WindowsSystem32 " \ > ./echo-win32.exe C:\Windows\System32 '"' '\' echo-win32.exe C:\Windows\System32 '' '\' cygwin does not treat \ as a quote if it is passed from non-cygwin shell. When a Cygwin program is launched from a non-Cygwin shell, I personally find it more natural for it to follow quoting semantics similar to Bash. I'm afraid that's not the case... > It sadly breaks builds driven by Windows-native tools since they expect > the standard command line handling. Isn't that the responsibility of the "Windows-native tool"? If it invokes cygwin build tool, it should pass the arguments in a way that conforms to cygwin's conventions. BTW, what exactly is the "Windows-native tool"? -- Takashi Yano <[email protected]> -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation: https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple