DMARC-Filter:	OpenDMARC Filter v1.4.2 delorie.com 5725fgaN278396
Authentication-Results:	delorie.com; dmarc=pass (p=none dis=none) header.from=cygwin.com
Authentication-Results:	delorie.com; spf=pass smtp.mailfrom=cygwin.com
DKIM-Filter:	OpenDKIM Filter v2.11.0 delorie.com 5725fgaN278396
Authentication-Results:	delorie.com;
	dkim=pass (1024-bit key, unprotected) header.d=cygwin.com header.i=@cygwin.com header.a=rsa-sha256 header.s=default header.b=FKZdn/+8
X-Recipient:	archive-cygwin AT delorie DOT com
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org A93F13858C78
DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1754113301;
	bh=5P4y4ebnrr+fVVX/6/i1QvLoQjkCghFkmRAOdfdN6Us=;
	h=Date:To:Subject:In-Reply-To:References:List-Id:List-Unsubscribe:
	List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:
	From;
	b=FKZdn/+8Lw8JYoQ5uLYPISiD27ZUGtdGUZJbUUIAu1fN2mMnsM413und2pKY9LvCM
	GgRpNc3BcSXlIW4tZF2o1PL5/o1KnjWta/uZgwsiGLwRCBbeUR+SErIHzqe0RRhK6o
	AN29TH/Ob8bmLOGySbi5GYZLMGaqtT1i9W9nJ+N4=
X-Original-To:	cygwin AT cygwin DOT com
Delivered-To:	cygwin AT cygwin DOT com
DMARC-Filter:	OpenDMARC Filter v1.4.2 sourceware.org 828C63858D1E
ARC-Filter:	OpenARC Filter v1.0.0 sourceware.org 828C63858D1E
ARC-Seal:	i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1754113243; cv=none;
	b=iHVAxGSf3mUe2Ia8enOrre0A5uMpuWC/5OvkWFkUkEAOwhPEcXzFQNeDdhPiF5qyWFcF7Gb5rP3T89JU42fz8naWB7j8QHS3wC06fCLxeOgod4Ne8yRCzaZ5/CJdaDr0o5Dekea/GpZAYl6zynfOjzU3VcLc/AYhDp95ntZYfVg=
ARC-Message-Signature:	i=1; a=rsa-sha256; d=sourceware.org; s=key;
	t=1754113243; c=relaxed/simple;
	bh=qZ9TS2dABRIuX6lsKlOJp2KCZmgXuRK6DwWuBxpYGdw=;
	h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version;
	b=Df++fhZFkHrIspIY+BOHQbJwWNeHhwW4ao088pKKjn0w0lsZnZusx5KCUtg/JI/eshHJClMgqElkD3Zeqjiz+jLoKByPBprA4Yc1iBI05Fopk0Dl609rMGfgcbYMmAS88pnRG4VMUwfZo87leTEnpZhmX7X66aNQ5/uglMLhXzA=
ARC-Authentication-Results:	i=1; server2.sourceware.org
DKIM-Filter:	OpenDKIM Filter v2.11.0 sourceware.org 828C63858D1E
Date:	Fri, 1 Aug 2025 22:40:42 -0700 (PDT)
X-X-Sender:	jeremyd AT resin DOT csoft DOT net
To:	cygwin AT cygwin DOT com
Subject:	Re: Incorrect command line handling when launching Cygwin program
	from Windows
In-Reply-To:	<20250802140151.674d96f806911c2db06c88cb@nifty.ne.jp>
Message-ID:	<cb1a1c52-9c7d-8fbb-e724-a22fa9acc1a2@jdrake.com>
References:	<AS8PR03MB7539A2A8333F01580829C8DB8D27A AT AS8PR03MB7539 DOT eurprd03 DOT prod DOT outlook DOT com>
	<20250801224236 DOT d52cdaf32913054e21711a12 AT nifty DOT ne DOT jp>
	<AS8PR03MB7539945DA4EFCF7604405E378D26A AT AS8PR03MB7539 DOT eurprd03 DOT prod DOT outlook DOT com>
	<20250802140151 DOT 674d96f806911c2db06c88cb AT nifty DOT ne DOT jp>
MIME-Version:	1.0
X-BeenThere:	cygwin AT cygwin DOT com
X-Mailman-Version:	2.1.30
List-Id:	General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe:	<https://cygwin.com/mailman/options/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=unsubscribe>
List-Archive:	<https://cygwin.com/pipermail/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-request AT cygwin DOT com?subject=help>
List-Subscribe:	<https://cygwin.com/mailman/listinfo/cygwin>,
	<mailto:cygwin-request AT cygwin DOT com?subject=subscribe>
From:	Jeremy Drake via Cygwin <cygwin AT cygwin DOT com>
Reply-To:	Jeremy Drake <cygwin AT jdrake DOT com>
Errors-To:	cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com
Sender:	"Cygwin" <cygwin-bounces~archive-cygwin=delorie DOT com AT cygwin DOT com>

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

- Raw text -