From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by melb.werple.net.au (8.7.5/8.7.3/2) with ESMTP id UAA06564 for ; Wed, 24 Jul 1996 20:00:59 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id FAA06566; Wed, 24 Jul 1996 05:53:25 -0400 (EDT) Resent-Date: Wed, 24 Jul 1996 05:53:25 -0400 (EDT) Message-Id: <199607240952.LAA00210@hydra.ifh.de> To: zsh-workers@math.gatech.edu (Zsh hackers list) Subject: Re: Bug in case stmt with '(' In-reply-to: "schaefer@candle.brasslantern.com"'s message of "Tue, 23 Jul 1996 14:55:53 MET." <960723145553.ZM3351@candle.brasslantern.com> Date: Wed, 24 Jul 1996 11:52:18 +0200 From: Peter Stephenson Resent-Message-ID: <"v21RK2.0.Wc1.KAVzn"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/1753 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu schaefer@candle.brasslantern.com wrote: > Given the choice of: > > 1. The "current" behavior, i.e. spaces ARE significant only when the > optional leading paren is there; > 2. The POSIX behavior, i.e. spaces are not significant in case patterns; > 3. Spaces are never significant in glob patterns anywhere. > > I'll take (2) before I'll take (3). My solution is equivalent to (2), > because it makes the spaces insignificant whether or not the opening > paren is there. This seems to me the best solution. It seems to create the minimal disruption to existing zsh users and to would-be POSIX users. Changing glob semantics more widely worries me --- even if done logically. Shells just aren't logical anyway. > I can't find any case where zsh doesn't permit '(' to be a glob metachar. Actually, there's one place we had to handle syntactically specially: [[ ($foo = (bar|rab)) ]] The first and matching `(' do grouping, then following the `=' zsh has to be told to expect glob patterns. I've never seen a problem with this, though, and the upshot is that `(' does pattern matching when you want it to. On something which is related, I've never been quiet happy with this: [ ( foo = bar ) ] (note no globbing metacharacters inside the parentheses). As test is an ordinary builtin, it simply gets called with the single argument `( foo = bar )' --- the parentheses are not stripped, which has non-zero length, so the test is true. In fact, parentheses here are effectively not treated as glob metacharacters. I felt rather guilty about this: some time ago I allowed spaces inside parentheses because I couldn't think of a good reason not to, and because it seemed to work better with glob modifiers --- things like *(:s/foo/bar/) --- which appeared in the same patch, rather than from any fundamental syntactical reason. Before, the shell would have reported a syntax error on the above test and the user would have known to quote the parentheses. This is what ksh88 does. Perhaps it should be subject to nomatch testing (which it isn't at the moment), perhaps to stripping of the parentheses, too. -- Peter Stephenson Tel: +49 33762 77366 WWW: http://www.ifh.de/~pws/ Fax: +49 33762 77330 Deutches Electronen-Synchrotron --- Institut fuer Hochenergiephysik Zeuthen DESY-IfH, 15735 Zeuthen, Germany.