On Sat, 2 Aug 2025, Takashi Yano via Cygwin wrote: > 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.
What standard command line handling is that? As a background, on Windows command lines are passed to processes as a single string, rather than as an array of strings like POSIX, and it is the responsibility of every process to make of that string what they will. Because of the prevalance of C, this is ususally to split it into an argv[], but it doesn't have to be. The net result of this is that you not only have to worry about the quoting and escaping rules of your shell (do you escape with backslash? caret? backtick?), you also have to worry about the rules of the program being run (cmd.exe with or without /S, Cygwin vs Microsoft CRT). There is something of a de-facto "standard command line handling" which is "what msvcrt does to populate argv[] before calling main", but that's not foolproof either: reference a recent bruhaha about a "worst-fit" vulnerability. It seems the crt will use best-fit and default replacement characters when converting the command line string from the native 2-byte unicode to the ansi codepage for char ** argv. That can result in unicode quote characters turning into ascii quotes, and in unmappable unicode characters turning into question marks, which then might end up treated as wildcards by the application. -- 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
