From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 79970 invoked by alias); 4 Sep 2019 16:20:43 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 79958 invoked by uid 89); 4 Sep 2019 16:20:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 spammy=henry, square, Henry, escaping X-HELO: smtp-out-no.shaw.ca Received: from smtp-out-no.shaw.ca (HELO smtp-out-no.shaw.ca) (64.59.134.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 04 Sep 2019 16:20:41 +0000 Received: from [192.168.1.114] ([24.64.172.44]) by shaw.ca with ESMTP id 5Y1NizmHCUIS25Y1OiHdiX; Wed, 04 Sep 2019 10:20:39 -0600 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" References: From: Brian Inglis Openpgp: preference=signencrypt Message-ID: Date: Wed, 04 Sep 2019 16:20:00 -0000 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: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00026.txt.bz2 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