From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 115405 invoked by alias); 5 Sep 2019 19:05:13 -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 115397 invoked by uid 89); 5 Sep 2019 19:05:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Sep 2019 19:05:12 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C81BB7F75C for ; Thu, 5 Sep 2019 19:05:10 +0000 (UTC) Received: from [10.3.116.234] (ovpn-116-234.phx2.redhat.com [10.3.116.234]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7CC355C25B for ; Thu, 5 Sep 2019 19:05:10 +0000 (UTC) Subject: Re: Command line processing in dcrt0.cc does not match Microsoft parsing rules To: cygwin@cygwin.com References: From: Eric Blake Openpgp: preference=signencrypt Message-ID: <0037aca6-e714-4e0a-53b8-18bbc582662a@redhat.com> Date: Thu, 05 Sep 2019 19:05:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="sgMBXYBU6LPc4auvOftnKbWTWR9u5Vb3K" X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00045.txt.bz2 --sgMBXYBU6LPc4auvOftnKbWTWR9u5Vb3K Content-Type: multipart/mixed; boundary="2M2cnD48jIvHJBbGuz9om5TzfDnBUa5Sw"; protected-headers="v1" From: Eric Blake To: cygwin@cygwin.com Message-ID: <0037aca6-e714-4e0a-53b8-18bbc582662a@redhat.com> Subject: Re: Command line processing in dcrt0.cc does not match Microsoft parsing rules References: In-Reply-To: --2M2cnD48jIvHJBbGuz9om5TzfDnBUa5Sw Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Content-length: 1745 On 9/5/19 1:31 PM, Stephen Provine via cygwin wrote: > My mistake - I'm very aware of the quoting rules, yet in my test script f= or this > scenario I forgot to quote the arguments. However, if POSIX rules are bei= ng > implemented, there is still something I didn't expect. Here's my bash scr= ipt: >=20 > #!/bin/bash > echo "$1" > echo "$2"=20 > echo "$3" >=20 > And I invoke it like this from a Windows command prompt: >=20 > C:\> bash -x script.sh foo bar\"baz bat > + echo foo > foo > + echo 'bar\baz bat' > bar\baz bat > + echo '' >=20 > Not expected. Why not? That obeyed cmd's odd rules: The moment you have a " in the command line, that argument continues until end of line or the next " (regardless of how many \ precede the "). https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/23/ev= eryone-quotes-command-line-arguments-the-wrong-way/ Perhaps you meant to try: c:\> bash -x script.sh foo ^"bar\^"baz^" bat > Called from within Cygwin, the behavior is correct: >=20 > $ bash -x script.sh foo bar\"baz bat > + echo foo > foo > + echo 'bar"baz' > bar"baz > + echo bat > bat Moral of the story: POSIX rules are saner than cmd rules. >=20 > Can you explain this difference? The reason I ask is that if this worked, > the way Go constructs the command line string would be just fine. If Go is not constructing the command line string in a manner that matches that blog post, the bug would be in Go. Presumably, Cygwin is correctly quoting things any time it calls into a non-Cygwin process (but if not, give us a test case for us to patch cygwin, or even better submit the patch). --=20 Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org --2M2cnD48jIvHJBbGuz9om5TzfDnBUa5Sw-- --sgMBXYBU6LPc4auvOftnKbWTWR9u5Vb3K Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 488 -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEccLMIrHEYCkn0vOqp6FrSiUnQ2oFAl1xXGUACgkQp6FrSiUn Q2qM0Af+Mb9InXvvy2I/oplO65Ih0osN26OCTy+Q8PUzrhlypzqzuzqhiWLnl0O+ 5kkZjYCXkUDi7EBikZUviE3inb+BhE0T5PgtU8fjCyySLbWAWtjjw5N8Mdn/VBmJ xls2LQv1b8EKMjlAxz+82b2ULA//Ch4vE8rVDV6IGygVF7ba5qpjsi1QHGRSPiyT AVhYVPhGiPc4jary4xmZoYJ1epF7iHPUyJzw7AvQ5Hi2Y8mg1HtcNqIKs+wL/DAv qT3SCZPo+tuUCsXMha6N9cZWhHVE4bsz5WMAwQObjoxkYKRkdLhkoAY5g+NUPxcO wcLjyX55o0zbndgG3BqyXwwXMCdA4g== =Zxg+ -----END PGP SIGNATURE----- --sgMBXYBU6LPc4auvOftnKbWTWR9u5Vb3K--