DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:from:reply-to:to:subject:date:message-id
	:references:in-reply-to:content-type:content-transfer-encoding
	:mime-version; q=dns; s=default; b=Ht27P/mneQ+JyI7eLRw5v6SHIjMET
	9/+ouR148SRgsHS1IByKaMiO4CAqVpyY6jHE18gua+xRKa/tetdJOK1NhQXnZT3q
	O/he5oL6BNQYPXtuEbzrFxjTa9NqyyPh6Kz06OAvSxcAEUaAV16U3m7efo+KUcAZ
	s0dHqOLZ1kzi3o=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
From: "Stephen Provine via cygwin" <cygwin@cygwin.com>
Reply-To: Stephen Provine <stephpr@microsoft.com>
To: "cygwin@cygwin.com" <cygwin@cygwin.com>
Subject: RE: Command line processing in dcrt0.cc does not match Microsoft parsing rules
Date: Thu, 5 Sep 2019 23:45:44 +0000
Message-ID: <MWHPR21MB0845845AC5AD54E3A2EAA05EB9BB0@MWHPR21MB0845.namprd21.prod.outlook.com>
References: <MWHPR21MB08452919F35B1B0C5F0EB4DCB9BD0@MWHPR21MB0845.namprd21.prod.outlook.com> <MWHPR21MB0845F78385792965A94E0CD9B9BD0@MWHPR21MB0845.namprd21.prod.outlook.com> <MWHPR21MB084508155AB621C7AD81309CB9B90@MWHPR21MB0845.namprd21.prod.outlook.com> <MWHPR21MB08456D9F03AF8BD450E6AB2EB9B80@MWHPR21MB0845.namprd21.prod.outlook.com> <MWHPR21MB0845282E7582DC95ADF0F140B9BB0@MWHPR21MB0845.namprd21.prod.outlook.com> <MWHPR21MB084583452E7C41D0792C739EB9BB0@MWHPR21MB0845.namprd21.prod.outlook.com>
In-Reply-To: <MWHPR21MB084583452E7C41D0792C739EB9BB0@MWHPR21MB0845.namprd21.prod.outlook.com>
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-userprincipalname: tqbRAuEkEEOLiqJgDjvfPLARh27pLdnQBwhVBuqzCoNhjZmWo7p2bgWfnUTYfnZx6mdW4AWp3hXq9QvbNqtjdg==
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id x85NkM3u027959

On 9/5/19 5:46 PM, Eric Blake wrote:
> If you start a cygwin process from Windows, then cygwin1.dll is given
> only a single string, which it must parse into argv according to windows
> conventions (if it does not produce the same argv[] as a windows process
> using CommandLineToArgvW, then that's a bug in cygwin1.dll).  But on top
> of that, if you are using cmd.exe to generate your command line, then
> you must use proper escaping, otherwise, cmd.exe can produce a command
> line that has unexpected quoting in the string handed to
> CommandLineToArgvW, and the Windows parsing when there are unbalanced
> quotes can be screwy

Great explanation, it's very helpful.

I've been using cmd.exe to generate the command line for my tests, but the
original problem was when my compiled Go binary directly executes another
Windows process using the Win32 APIs like CreateProcess directly. Here's a
simple Go program that reproduces the issue:

package main

import (
	"log"
	"os"
	"os/exec"
)

func main() {
	cmd := exec.Command("C:\\cygwin64\\bin\\bash.exe", "test.sh", "foo", "bar\"baz", "bat")
	cmd.Stdout = os.Stdout
	cmd.Stderr = os.Stderr
	if err := cmd.Run(); err != nil {
		log.Fatal(err)
	}
}

The output of this process is:

foo
bar\baz bat


To prove it is not going through cmd.exe, I debugged the Go program
to the point that it calls the Win32 CreateProcess function, and the
first two arguments are:

lpApplicationName: "C:\\cygwin64\\bin\\bash.exe"
lpCommandLine: "C:\\cygwin64\\bin\\bash.exe test.sh foo bar\\\"baz bat"

So unless I'm missing something, bash.exe is not interpreting the command line
following the rules pointed to by the documentation for CommandLineToArgvW.

Thanks,
Stephen

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple