From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112418 invoked by alias); 11 Sep 2015 01:24:06 -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 112398 invoked by uid 89); 11 Sep 2015 01:24:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.0 required=5.0 tests=AWL,BAYES_50,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=no version=3.3.2 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 11 Sep 2015 01:24:04 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (Postfix) with ESMTPS id 9C3D42F2F86 for ; Fri, 11 Sep 2015 01:24:03 +0000 (UTC) Received: from [10.3.113.15] ([10.3.113.15]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t8B1O3MI029696 for ; Thu, 10 Sep 2015 21:24:03 -0400 Subject: Re: Group Permissions on root folders problem (Windows 10 TP build 10061) To: cygwin@cygwin.com References: <20150616155843.GE31537@calimero.vinschen.de> <20150905155916.8403bea8d4f631c1f7a314e3@nifty.ne.jp> <20150906114444.GA27066@calimero.vinschen.de> <20150910200439.bf06449af4f1e6efcb76676e@nifty.ne.jp> <20150910172348.GB26699@calimero.vinschen.de> <55F1BD86.1090001@redhat.com> <20150910173128.GD26699@calimero.vinschen.de> <55F1BF8A.2050907@redhat.com> <719333680.20150911033936@yandex.ru> From: Eric Blake Openpgp: url=http://people.redhat.com/eblake/eblake.gpg X-Enigmail-Draft-Status: N1110 Message-ID: <55F22D2E.3070801@redhat.com> Date: Fri, 11 Sep 2015 01:24:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <719333680.20150911033936@yandex.ru> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="juTRRjPjPnDAFWDQlG3McXjcnc9cJfjGF" X-IsSubscribed: yes X-SW-Source: 2015-09/txt/msg00171.txt.bz2 --juTRRjPjPnDAFWDQlG3McXjcnc9cJfjGF Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-length: 2753 On 09/10/2015 06:39 PM, Andrey Repin wrote: >>>> [ ... -a ... ] is not portable; there are some inherently ambiguous >>>> situations that it cannot handle. POSIX recommends that you spell it [ >>>> ... ] && [ ... ] instead. >>> >=20 > If a script author did not quote the indirect references, it is their fau= lt, No, even with proper quoting, the use of -a and -o creates ambiguous situations. For example, a naive read would claim that test "$var1" -a "$var2" sets $? to 0 only if both "$var1" and "$var2" are non-empty. But according to the POSIX rules, if $var1 is '!' and $var2 is '', then this MUST be treated as the negation of the unary operator '-a "$var2"', if the shell has a unary -a (bash does, dash does not). And in bash's case, '-a ""' is false (the empty string never exists as a file), so the negation is true, and you have a case where the -a version returned 0 in spite of one of the inputs being empty. To get what you naively wanted, you HAVE to use: test "$var1" $$ test "$var2" Another tricky one is test ! "$var1" -a "$var2" because some people naively assume it matches C precedence rules to mean: test \( ! "$var1" \) -a "$var2" while POSIX claims it means: test ! \( "$var1" -a "$var2" \) except that you can't use () to force the precedence, because POSIX says that 5 or more arguments to test causes unspecified results. But it is unambiguous what you meant when you write: test ! "$var1" && test "$var2" or ! { test "$var1" && test "$var2"; } > not an inherent "portability issue". It is inherently ambiguous to use -a or -o, so using them at all on unknown user input is risky. Furthermore, POSIX has explicitly marked -a and -o to be optional (only XSI systems have to have them) and obsolete (they may be withdrawn in a future revision of POSIX, because of their ambiguity problems). Therefore it is inherently a portability issue (as different shells have different behaviors, and future shells may have further different behaviors). > I don't see, how your statement could be valid. Then you haven't read POSIX: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/test.html > The "[ ... ] && [ ... ]" doesn't mean the same as testing two conditions = in > one statement. There is no semantic difference to testing in two statements, because [ is a shell builtin. It costs the same amount of work, and zero fork()s, either way. If you really are that opposed to using two shell statements, then remember that we are using bash, and spell it: [[ ... && ... ]] rather than using -a. At least THAT is guaranteed to work sanely, although it is not (yet) specified by POSIX. --=20 Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org --juTRRjPjPnDAFWDQlG3McXjcnc9cJfjGF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" Content-length: 604 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Public key at http://people.redhat.com/eblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJV8i0uAAoJEKeha0olJ0Nqjy8H/R6zXfOqhWr8VYwR39/+h9+C t4gK6fyGBXcXxOS96MV0Pq1dt3Y+X3jcodolRDy1tSXOTXyFbwCQUlsijOxVtqFa QQK0vIbc+wOvB3ljJiwV/dxRa67XR9X+OcVBgo2CjxixN5L1KjzKsiWDF+ypgbvJ 9yN97pKa06CtG8N7ciim0T8lMzCSxm7dAHj5NZdIhIqcsQ2BClVttJ8z81oa1kBz c/t62CuxYRbnX7zI/3CVgDTI/tzjdbZAGwwgYdLX9ECEVcr7Nj1GF2KNvmSGbdZL VjVEvtaSw99VCpz9AIfHscrOoXylwnVp9S/Z6sBF1XHB2ZsA5PjrNUhI7qi01XI= =xpeP -----END PGP SIGNATURE----- --juTRRjPjPnDAFWDQlG3McXjcnc9cJfjGF--