From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21436 invoked by alias); 27 Dec 2012 06:25:20 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 17500 Received: (qmail 24506 invoked from network); 27 Dec 2012 06:25:09 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <121226222458.ZM735@torch.brasslantern.com> Date: Wed, 26 Dec 2012 22:24:58 -0800 In-reply-to: <20121226100944.GB8145@localhost.localdomain> Comments: In reply to Han Pingtian "Re: priority problem of ":|" and ":*"" (Dec 26, 6:09pm) References: <20121224105241.GA24051@localhost.localdomain> <20121225231133.GA8145@localhost.localdomain> <121226011019.ZM32249@torch.brasslantern.com> <20121226100944.GB8145@localhost.localdomain> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: priority problem of ":|" and ":*" MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Dec 26, 6:09pm, Han Pingtian wrote: } Subject: Re: priority problem of ":|" and ":*" } } On Wed, Dec 26, 2012 at 01:10:19AM -0800, Bart Schaefer wrote: } > And in fact poring through the code it appears that rule 5 double-quoted } > joining is explicitly SKIPPED when the length is requested: } } But I think ":|" doesn't skip the double-quoted, so the "#" would get the } length of the result of ":|", because "#"'s priority is lower than } ":|"'s. Or when running in double-quoted, "#" will has a higher priority } ? Unfortunately you can't think of the parameter flags and modifiers like arithmetic operators. They don't have well-defined precedences. So it is almost meaningless to speak of # or :| having relative "priority." The numbering of the "rules" for parameter expansion in the manual describes the order in which operations are applied, and sometimes the rules do not cover all possible combinations. Those "rules" were derived after the fact by code examination, not made up ahead of time as a specification for how the code is suppose to work. In situations where the code and the manual disagree, code is definitive unless we are able to determine that (a) the description in the manual is more sensible and (b) nothing is going to break if we revise the code to match the documentation. I don't believe we've established (b) here. In this case rule 5 should have mentioned an exception for the # length expression as it does for the (@) array flag, and the description of SPEC in the ${#SPEC} documentation might have been qualified to explain that surrounding double-quotes are intentionally prevented from altering the semantics of the length calculation. To get what you expected, you must use a nested substitution.