DMARC-Filter: OpenDMARC Filter v1.4.2 delorie.com 572Gn9Xh403138
DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D508C3858D1E
Message-ID: <24582ba4-6d3b-4bf1-b7bf-7ee23decef4a@towo.net>
Date: Sat, 2 Aug 2025 11:02:48 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Incorrect command line handling when launching Cygwin program
 from Windows
To: cygwin@cygwin.com
References: <AS8PR03MB7539A2A8333F01580829C8DB8D27A@AS8PR03MB7539.eurprd03.prod.outlook.com>
 <20250801224236.d52cdaf32913054e21711a12@nifty.ne.jp>
 <AS8PR03MB7539945DA4EFCF7604405E378D26A@AS8PR03MB7539.eurprd03.prod.outlook.com>
 <20250802140151.674d96f806911c2db06c88cb@nifty.ne.jp>
 <cb1a1c52-9c7d-8fbb-e724-a22fa9acc1a2@jdrake.com>
Autocrypt: addr=towo@towo.net; keydata=
 xsDNBGNaf3QBDACVevqudcTSevLThXKQPU1QpaDxtGuYjtwmr7i9wXxVGih4Y4oxOJN4PYlu
 KBX9IVAI4651dA+xYtXuyIkWOPZWyyzkGKavQOn3Q7dk09oj7bh2IwOndpxXXde337D408EQ
 bQEGbMHr9lOWhSAideowzgCeFIvGTf2AovbPh97HpexJn1/HCRiRAhTNlrkS1DByUgCAeEMK
 fEr6aGM/Ou29MT+eTnQwOIZTnl9Z9LxM2FtqqMH3MycC7I2OoW3XXhuL8BPQdyJUjWa0/J11
 Oo5jFkRXtWenIns6jGn18oW72jnDmo9jXwwS+iZWAV6Y51nhD7jSC+3xs9ORmPCdtHUSpTr1
 zh67UueUJ3DUUNVuA25Hn/9EJMJ2L60BGUEr88NEB6pcZhmcwdkurAQeYT6t+frzBz2ctsoN
 BoxP/Xc02yd+z7hXWRRMrJWh9WHlQHA3Z4FfmyNhyPhs3MgKTJ1E9QfzGquigAmF3/k/Dc1m
 7cSOKhGYhpEJdSpdXccJFKkAEQEAAc0cVGhvbWFzIFdvbGZmIDx0b3dvQHRvd28ubmV0PsLB
 BwQTAQgAMRYhBHUiRKsHn5d8BpWdP8bz0e72Bp0CBQJjWn93AhsDBAsJCAcFFQgJCgsFFgID
 AQAACgkQxvPR7vYGnQKSMAv8Di+8MXB2mcfsemRdShfLLKcLOv+d0CXAtPVaY3XKxbKpRvC9
 +AAT5wIHYjQft77/b2y87vGIh+nQ5hKLtNtQPSDtqG/Igkb5jAXpLi28fSUzgM96DvARmwve
 5wSnAU3prxH+Y63YpOpslEcGMRoEtYCDy1ANMYPcEZT/YvDd4CplyyEai4VYrw3/LsESDYlY
 GK6uMQzZ1jl2cNOUFu6BwLUeZIcwaqGto8n4R4nbf4jxUEpa21bWBPqE+Jf49uipjPr/iJ72
 5HbdWuuCfyTTJEJjfNEBigWP2RXM9iNDcO61V3aEjh76tThfBK2MMlLWfZkQaQziu24x8R4B
 I0efJYWBX2Sv2qnsH/EWj7FUIZjRqGG7LnWHLShfG6yjSOTOWYi8BbsvoftpaLWgZX28aGX4
 uzuSZ5L0caXh/pr/gSgqoH/YbuFIgqtQH4seOBgTybd22Vpe78rnc+8450pN8qwchHAZaJka
 UxS0SpYxXzXmHUKILA4C43s0U/z2Mez9zsDNBGNaf3cBDADeJ7paMrb6f1+k8wM7tyk0/Ded
 KX/pOejt/D20Ceerw2iL/4tUmBL+A3ic2yjiSFUSsEfHwgCVwKrn4MwZtkesdiphm2lk6xWc
 k1ENCQy44QwQT6UZ/mHWYWcj5LS6ua183x1zdn9iF3lv150nm/ssw56D7USz/ap1Vh0lf5te
 D+CIheGLocVDqxWiu7rHP8jKRWFgq/+OU6HKX8p2Yv1oYsykh9qF2bFzawLDS+S1VbfRicfD
 G0RtceL/BAf7b6UE5u9TGdfrFEa2TKZeS/FS/ViKUfwsXQIki1sWt2FQENbuDY28vxyR46ZZ
 0gixDCFUoBw5pkmOGVQa+1RQYrRqlN4X0CAgp7mFVeEHl5NTgiL1bemkQVmHOUDG+CzNg+Lk
 UGoedAtT672l3JjrnSs4j8zNshpgV2OfAhAC+V9XvqCjMnxzVfXkVlbuWpPfUWQeFclLGg8P
 agpQUE0Ux+VV4DoeQCxYEnRCf/n7n+IRfILj5+2l6Zw4M7zSu6ii0tUAEQEAAcLA9gQYAQgA
 IBYhBHUiRKsHn5d8BpWdP8bz0e72Bp0CBQJjWn97AhsMAAoJEMbz0e72Bp0CQr4L/REdT0SF
 mbapnZIe92THCdtAUgwEv8VdNiNFBJelz8P/fuXuNPtisYvQQD4e64zpWe2UC4Cxo9DUk/pW
 6Qci1xaXRKEiSPjHdSGGVB1PFIcqiS75GCf/ga/Dnfsy0Y4Uh6OGTQnkvZLBCe3vvcVLDQ7F
 PuV79zA9/eOeOW6aGoO6bq/wH+z96f9LyTITkQDy07fm6JYTGuzAoJE2AEboU1mgbtlx+tAa
 QFkpAQkp2g1Vhc3A7k4vntlHOrjMC+uVFh7QTGFfIlLRF6izUjSe6EZ06LErzlIiE05RP3yF
 FSRWidW0wze26peYlxYVgH1+T9wMTW2oiTBybfAMHBAxUP7Gr1WUo/oJEr0srWhatz8AwydP
 y7NwFbdpYn0NcFBaIlLW/JL11Eovwlivow+oGpzGFuuzSuflp2q9s2JWtn4EhW0kEs93D0LP
 iuJWvRaCZ6aD3uF3FMW8wyVWZYsLrzune2jH8w/uKMprDEOGOm+BcyhEFedTyY1ygbZKl+0G kQ==
In-Reply-To: <cb1a1c52-9c7d-8fbb-e724-a22fa9acc1a2@jdrake.com>
UI-OutboundReport: notjunk:1;M01:P0:zKlPaPsvCx0=;V5v+LUGuuQX074jd7BkycnqjY/O
 6vHbqFN2WBa/iDC9LAANQTncCWMKxqT/d2tdLlMfNc/rOTtqAwG4gVrx8UHUen2CqwQSJ8oF4
 kq0mVvWoMweIaouraD4mgXdHgcSWkmCDnGAut6WuIgxFpnH9lx7do10W6I0fNSIrjGsZfTx1s
 ILCp5MiJqVwA0eyMGOgQ5U+mdC8fnPur3ojpF6BAQQeJV9GWZ8Z9h2QyIIYZbttF64YZRK1Ip
 ONzSyw9jXueVSEMjZazg023Iuj3Hsvr03ArP3fbSbAHRjW4o9VA+wg7LjD2j2H6h/2g8aSAYY
 /jVaViK7m0ngdqRW+dAkZF4hv3ygM2C1FYJXnNXIUgn0oXBVmVM3KmWJAk+C64N6NsmxybVzh
 6grLbupiS7rixy/I1dWXiG7jICrzeK2O72DaVWBu7mrmvtKjtWqi91xlhLiuYy1qP8hTK97mH
 qXnc3g/RlbtwS2dUQhJkW1xTo9SrvA4qX6b4YitiuL9i5kjcMQkNR6oyjeluj6uoXtzReAdjf
 8oyIUCSoqTzDSM+gZ9SKMt1n+DguZ+7IlBW5WtOnq9TIyDGVk/BJFt2jy3ckLf5yEuKkbI3tw
 WrUTlrxxmdSm8X3sla4LaKAZDBI1C97d/Ih/WZFkmoRkuP3hx32cxmKSYEA1Q0INYd5uY344z
 fPtNgRepcbHT1fcPiKB0oQ48Dgo2VKKxiq94pw++T67kYLg+XhRtRASgwHuOsNOE5w91AdyZe
 THPGjFR7pVX0TymtuEUgTvOEQ23/Wg/PyUCHP6WuN3eoKB+bk89SX9D52vqN52o/C5Iae696C
 PTWCa4u6W8nbBN8FjtQ7pXy52jz4pR97jOflYkw3kImjkAlBOFG9rZS5I0sq5se9WKkSfXgoy
 hM+58DAY/RbN3DXf5CBkRn2HkXVeFcqvRyL2+rESCCvYTkRYny3urCd/X0QZIA7rkyvxKNnhF
 yNqaP5nzuAPGlAZWmvrHk0rqvhJR5XbvttMkFIH03WgCNDBRqUuLpSCP9xI10lF6YlVvnP/8/
 Lzi3CqV5lCyIBKRL+TUebmEnpSEUFb8b8H8vfnBzyuotSuFdmXMYtFOzhgyZvGx8UTMV5fi2C
 cKwJshVHV55q++q3qKZV5JcmhDjIpeGbHbJclOvZkQ4/YTAAbOZJ1ykheGHr73zlJURNdIo3C
 aWrltouWqn0Q8yMc06EAI21TCMwdJqq8oog2sCOtx/TSnNXD0l9ffWRl7YWnWWIEXXuzuWHP3
 x2qDpaTU9cGZvgn/Bvp0LoLkqGppuvuzKW1TQ4YYHipRHoTEfmQUQZi/eywPdsOTXuFLk9OLX
 Sumq5+3EDDMT7hHCtG4r04Uzi/3Ny+FI0KPKg0DeH0vxq0V0+6pWnY9y7qQM2xvV3fK7+2oOI
 lct8VxCEXzZ2nZOHDS4RuhDbC/uLv1IKQ0Y1x4ZMqWOYF2yOlZKzk2BeIQjNfz0giS0kOaMip
 d9FWFx5SyrLNmjysN+uKYt0eJ0EYtQ0qqwwAK4rtm7ejRonSdLKNAYBfCd+/A8tohj7ktUH+1
 1m/a0rLikUhkP8+S+jRg3XLW4M9s4SrIhBWYrzGBTUNZoXeRmefFzjvcEOJSOQ==
Precedence: list
From: Thomas Wolff via Cygwin <cygwin@cygwin.com>
Reply-To: Thomas Wolff <towo@towo.net>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Errors-To: cygwin-bounces~archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces~archive-cygwin=delorie.com@cygwin.com>


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