Am 02.08.2025 um 07:40 schrieb Jeremy Drake via Cygwin:
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.
This was discussed extensively years ago, if I remember correctly with
the result that with every conceivable solution there will remain
unpleasant border cases due to the incompatible command line handling
paradigms of POSIX and Windows.
Please consider this if you try to make new proposals...
--
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
