From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12267 invoked by alias); 14 May 2015 16:18:00 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 35131 Received: (qmail 26039 invoked from network); 14 May 2015 16:17:58 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 X-AuditID: cbfec7f4-f79c56d0000012ee-85-5554cab4d5f0 Date: Thu, 14 May 2015 17:17:16 +0100 From: Peter Stephenson To: Martijn Dekker , zsh-workers@zsh.org Subject: Re: 'case' pattern matching bug with bracket expressions Message-id: <20150514171716.69cd99c9@pwslap01u.europe.root.pri> In-reply-to: <5554C3A5.4030205@inlv.org> References: <55549FB2.80705@inlv.org> <20150514154238.0e547ff0@pwslap01u.europe.root.pri> <5554C3A5.4030205@inlv.org> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrLLMWRmVeSWpSXmKPExsVy+t/xa7pbToWEGjydxW5xqivF4mDzQyYH Jo+/aycxeaw6+IEpgCmKyyYlNSezLLVI3y6BK6Pjeg9jwSWeio3rG1kaGC9ydjFyckgImEi0 PLjACmGLSVy4t56ti5GLQ0hgKaPEgu8XmCCcBiaJOV3TWCCcbYwSO+5sZgJpYRFQlTiw9wM7 iM0mYCgxddNsRhBbRMBK4tPMP2C2sICjxK/+TrAVvAL2Ese+trGB2JwCGhL/L39lAbGFBMol nj96BVbDL6AvcfXvJyaIk+wlZl45wwjRKyjxY/I9sHpmAS2JzduaWCFseYnNa94yQ8xRl7hx dzf7BEahWUhaZiFpmYWkZQEj8ypG0dTS5ILipPRcQ73ixNzi0rx0veT83E2MkED+soNx8TGr Q4wCHIxKPLwr1INDhVgTy4orcw8xSnAwK4nw1m0KCRXiTUmsrEotyo8vKs1JLT7EKM3BoiTO O3fX+xAhgfTEktTs1NSC1CKYLBMHp1QDY/q27DY+L5bv0qVHTV7s+SdYy8FV2yFiV3TQ7py+ zdo+4WDL5FiO/IfJVYtn1zTafTKVelnHuvwJz32JK7u5n836OL/GMDWsiHkTxyPFl2WmBtwx Trf5M5Uifc40HNmmJF6lnrtgC2+OcX705akfHhsueLk+/86nV7XvbkWbm7tPaNSq6W9TYinO SDTUYi4qTgQAkA1VdGACAAA= On Thu, 14 May 2015 16:47:49 +0100 Martijn Dekker wrote: > What confounded me is that this applies even if the pattern is [$var] or > even ["$var"], where $var is empty. This causes the bracket pattern to > unexpectedly swallow anything that follows it if $var is empty. That > seems very unexpected and undesirable to me, particularly since, as far > as I know, zsh appears to be the only shell that chooses to handle it > this way. Sorry about the multiple emails... I don't *think* the following patch makes anything worse, but notice you're in any case on fairly soggy ground here, even in bash: $ var= $ [[ ']' = [$var]*[$var] ]] && echo matches matches and presumably Chet would agree with me that's required by the standard. pws diff --git a/Src/pattern.c b/Src/pattern.c index 05dcb29..4e5e8a1 100644 --- a/Src/pattern.c +++ b/Src/pattern.c @@ -1405,7 +1405,16 @@ patcomppiece(int *flagp, int paren) starter = patnode(P_ANYBUT); } else starter = patnode(P_ANYOF); - if (*patparse == Outbrack) { + /* + * []...] means match a "]" or other included characters. + * However, to be a bit helpful and for compatibility + * with other shells, don't take it in that sense if + * there's no further active "]". That's still imperfect, + * but it's all we can do --- we're required to + * treat [$var]*[$var]with empty var as [ ... ] + * containing "]*[". + */ + if (*patparse == Outbrack && strchr(patparse+1, Outbrack)) { patparse++; patadd(NULL, ']', 1, PA_NOALIGN); }