From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129856 invoked by alias); 9 Sep 2019 16:41:45 -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 129849 invoked by uid 89); 9 Sep 2019 16:41:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,RCVD_IN_DNSWL_NONE,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.1 spammy=Friday, stephen, heres, friday X-HELO: NAM04-BN3-obe.outbound.protection.outlook.com Received: from mail-eopbgr680111.outbound.protection.outlook.com (HELO NAM04-BN3-obe.outbound.protection.outlook.com) (40.107.68.111) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 09 Sep 2019 16:41:41 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=j9LH5MIrPzUaIvqujd+hkeZo89bQ3kIJW1SlUszFMtvgxADGgwxbDeLvNgka2g+gYgLhxUg3yNjpurqZj8iSnSEwa0ZM1Eifi7kNjtuhHiPA3M7k4HTJxfQmWklaZ3zenO9VSS/IHm5VDPRpu4KmNnrXwHBPDRcy36O9s0q8VVQdCWXWO5l1gPqk2cXh+mtegaxLNNwMjjbLsku6E5NkfFzOztLwNfz4uPNPODTX3TU90a3Jg+c9Ncmn0IA4JWq6tRj+LXgG+YzG/XfbSzoyoHFl0bFnX3KpLxvPWfeQ/L+KMOghqFtiTwmHMGuQVysWDhX9S5j5JBD2G/NcpPtnPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TC9+/s+2Y1vckKKS+ur1H+c/NCHBrO0l+bOKFRhC1eI=; b=W5UGAkcW7seHZ3cjRkRBkZKX6CEPEqwrLo5OCEGf9h3xjd/HFX+yEKkzQ52uXkcQY6pmrLFEWwpsEiwltpsmennQkH1EUCgRdywrA6yKWJ+xSI5SXu5J1IuhrE+WICOKAF8BJLKOrboo1Fc3jvyXN/hKPJ8VMTEqE3CU0Foszc0Yi5JMa3DAwmU7gqEZVOoS1lsXZo5ZnrbQHx5/M/8mEjMozX3SNlAw8z5woIIYBqa0YVhkblI1g/L8rZtXF3V/sEiWXCWEMcmX+XARVrqsvWUubYtfd0v7kEsDj4K4+BiidqlDWMF+b3mLZs9cu8EZxpEq1rcOWg3VJwdG8X/g6Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TC9+/s+2Y1vckKKS+ur1H+c/NCHBrO0l+bOKFRhC1eI=; b=JjCqkUVW/oczG5fjk2CMQasQfcRB/1uiRBvnYrylURBV7vIT/BxWjI2tctRgqRsI9Ec540Z64D7tEvpv2UUv//A5cn3ttpX5crFVoqgbfhDNUQgkk0VNl4iUA5af17eRf5RneL1k5lpSVqTv8q7doDpyn4UHKQlf1PU5g37Afd8= Received: from CY4PR21MB0838.namprd21.prod.outlook.com (10.173.192.139) by CY4PR21MB0695.namprd21.prod.outlook.com (10.175.121.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.7; Mon, 9 Sep 2019 16:41:37 +0000 Received: from CY4PR21MB0838.namprd21.prod.outlook.com ([fe80::f5a9:7dbf:d9f1:a1cd]) by CY4PR21MB0838.namprd21.prod.outlook.com ([fe80::f5a9:7dbf:d9f1:a1cd%13]) with mapi id 15.20.2284.004; Mon, 9 Sep 2019 16:41:37 +0000 From: "Stephen Provine via cygwin" Reply-To: Stephen Provine To: "cygwin@cygwin.com" , "anrdaemon@yandex.ru" Subject: RE: Command line processing in dcrt0.cc does not match Microsoft parsing rules Date: Mon, 09 Sep 2019 16:47:00 -0000 Message-ID: References: <135817606.20190906233445@yandex.ru> In-Reply-To: <135817606.20190906233445@yandex.ru> authentication-results: spf=none (sender IP is ) smtp.mailfrom=stephpr@microsoft.com; x-ms-exchange-purlcount: 3 x-ms-oob-tlc-oobclassifiers: OLM:10000; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Dlg3WBAQH0jJhuw5vAjHfXgPLNLROytFlNlnRhIrwltabRn1hHCv07C84GIV9WWh+jx5iJXW7QUmmSLhI5q3AQ== X-SW-Source: 2019-09/txt/msg00102.txt.bz2 On 2019-09-06 13:35, Andrey Repin wrote: > CMD escape character is ^, not \ You are correct about the cmd.exe interpretation, so my test cases were buggy, but Go invokes other executables using CreateProcess directly and is not subject to the additional set of command line processing rules that are used by cmd.exe. If you see the last exchange with Eric, I think it is clear that there is a= case missing in the Cygwin processing rules that becomes a problem when a calling process directly reverses the rules, specifically when an argument value does not itself need to be quoted but it has a double quote in the value. This is rule 4 in what I found to be the most definitive reference: http://daviddeley.com/autohotkey/parameters/parameters.htm#WINCRULESCHANGE And see the fourth example in section 5.4. However, the *safest* way to construct a command line is to avoid this case and make sure to always double quote an argument that contains double quotes. The official algorithm from a Microsoft source was previously posted by Eric: https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/ev= eryone-quotes-command-line-arguments-the-wrong-way/ Interesting that there's actually nothing in this article that specifically means it *shouldn't* be ok to do what the Go algorithm does, it just happens to be simpler if you don't worry about that case. FWIW, .NET Core uses this algorithm: https://github.com/dotnet/corefx/blob/master/src/Common/src/CoreLib/System/= PasteArguments.cs Which I think is probably pretty good validation that it's the right one to= use. So, the outcome of all of this is that Go should probably update their logic as it's based on the wrong official source. I plan to follow up there. If t= here is any interest in the future to correct the parsing behavior in Cygwin, the information needed to do that is in this thread. Personally, I think that if Cygwin fixes the problem it's easier to recompile all those binaries than t= ry to locate all potential source calling processes to make sure they follow the right algorithm (Go isn't right, what about Node, Python, etc...) But I'm not going to push on this point as I can work around it for my case. Thanks, Stephen -----Original Message----- From: Andrey Repin =20 Sent: Friday, September 6, 2019 1:35 PM To: Stephen Provine ; cygwin@cygwin.com Subject: Re: Command line processing in dcrt0.cc does not match Microsoft p= arsing rules Greetings, Stephen Provine! > On 2019-09-04 23:29, Brian Inglis wrote: >> As standard on Unix systems, just add another level of quoting for=20 >> each level of interpretation, as bash will process that command line,=20 >> then bash will process the script command line. > My mistake - I'm very aware of the quoting rules, yet in my test=20 > script for this scenario I forgot to quote the arguments. However, if=20 > POSIX rules are being implemented, there is still something I didn't expe= ct. Here's my bash script: > #!/bin/bash > echo "$1" > echo "$2"=20 > echo "$3" > And I invoke it like this from a Windows command prompt: > C:\> bash -x script.sh foo bar\"baz bat > + echo foo > foo > + echo 'bar\baz bat' > bar\baz bat > + echo '' > Not expected. Called from within Cygwin, the behavior is correct: Again, fully expected. > $ bash -x script.sh foo bar\"baz bat > + echo foo > foo > + echo 'bar"baz' > bar"baz > + echo bat > bat > Can you explain this difference? CMD escape character is ^, not \ > The reason I ask is that if this worked, the way Go constructs the=20 > command line string would be just fine. No. -- With best regards, Andrey Repin Friday, September 6, 2019 23:33:46 Sorry for my terrible english... -- 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