DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:reply-to:subject:to:references:from:message-id
	:date:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=khC5bfdRtEIVP8cc
	boL3sCmKqgiaTzNwK9nBgI+kzymXhXSIOmsD6BUbUMGGtT+2ZhNomx4sLtJkVpms
	8WFDKolOhkM+0lPpWHcS5nZa6KIqhFj8jM3mIHLAXA+JHYr3bfrkmrF2NYD4Wsa5
	EswxrhjKTdEjGjkYFZ0fkzwNf44=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Reply-To: Brian.Inglis@SystematicSw.ab.ca
Subject: Re: Command line processing in dcrt0.cc does not match Microsoft parsing rules
To: "cygwin@cygwin.com" <cygwin@cygwin.com>
References: <MWHPR21MB08452919F35B1B0C5F0EB4DCB9BD0@MWHPR21MB0845.namprd21.prod.outlook.com> <MWHPR21MB0845F78385792965A94E0CD9B9BD0@MWHPR21MB0845.namprd21.prod.outlook.com> <MWHPR21MB084508155AB621C7AD81309CB9B90@MWHPR21MB0845.namprd21.prod.outlook.com>
From: Brian Inglis <Brian.Inglis@SystematicSw.ab.ca>
Openpgp: preference=signencrypt
Message-ID: <f5a94050-695c-d3e9-594b-a8f9972266ac@SystematicSw.ab.ca>
Date: Wed, 4 Sep 2019 10:20:37 -0600
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <MWHPR21MB084508155AB621C7AD81309CB9B90@MWHPR21MB0845.namprd21.prod.outlook.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 2019-09-03 10:38, Stephen Provine wrote:
> On 2019-08-30 21:58, Brian Inglis wrote:
>> Not being in the same Cygwin process group and lacking the appropriate interface
>> info indicates that the invoker was not Cygwin.
> 
> Should I interpret this to mean the "winshell" parameter is not an accurate
> statement of what I thought it was for and because there is no way to reliably
> determine if the calling process was from Cygwin or not, behavior like I suggest
> is actually impossible?

Reread the rules in the article you quoted, carefully, then read:

http://www.windowsinspired.com/how-a-windows-programs-splits-its-command-line-into-individual-arguments/
[also see linked articles about cmd and batch file command line parsing]

and ask if you really expect anyone else to use or reproduce this insanity,
rather than a sane POSIX parser?
Once again MS "persists in reinventing the square wheel", badly [from Henry
Spencer's Commandments].

What does the Go command line parser actually accept, does it really invert the
parse_cmdline or CommandLineToArgvW rules, and which?

That winshell parameter is set in dcrt0.cc calling build_argv, based on whether
the parent process was Cygwin and an argv array is available preset by the
Cygwin parent, or not and globs are allowed to be expanded, such that the
command line args, quotes, and wildcards have to be handled by the program
according to POSIX shell command line quoting, field splitting, and pathname
expansion rules, respecting $IFS:

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html

The similar flag in spawn.cc based on the exe or interpreter exe being under a
Cygwin exec mount in realpath.iscygexec() decides whether the argv array can be
passed a la Unix to a Cygwin child, or a Windows command line needs to be built
with Windows argument double quoting and escaping where required.

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.

--
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