confusing passage in zshexpn(1)

confusing passage in zshexpn(1)

[Frank Terbeck]

Hi list,

Someone on IRC wondered about a problem with the following passage in
zshexpn(1):

[snip]
 x##    (Requires EXTENDED_GLOB to be set.) Matches one or more occur-
        rences of the pattern x. This operator has high precedence;
        '12##' is equivalent to '1(2##)', rather than '(12)##'. No
        more than two active '#' characters may appear together.
[snap]

Because of this part of the manual he tried this:
% setopt EXTENDED_GLOB; touch 12222; echo 1(2##)
zsh: unknown file attribute

That's because of the trailing parentheses in the globbing pattern.
But the manual suggests that this should work.

How could this be included in the manual?
How could the fact be included, that this pattern is okay to use in
the following position?

[snip]
% file=12222
% [[ ${file} == 1(2##) ]] && print match.
match.
[snap]

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: confusing passage in zshexpn(1)

[Bart Schaefer]

On Dec 12,  1:21am, Frank Terbeck wrote:
}
} Because of this part of the manual he tried this:
} % setopt EXTENDED_GLOB; touch 12222; echo 1(2##)
} zsh: unknown file attribute
} 
} That's because of the trailing parentheses in the globbing pattern.
} But the manual suggests that this should work.

People are WAY too "suggestible."

Not every fragment that appears as part of a sentence is desgined to be
usable as a literal stand-alone example!  If it were, it would be on a
line by itself, indented, and probaly set off with blank lines before
and after as well, not stuck into a sentence with quote marks around it.
 
} How could this be included in the manual?

As it happens, this fragment DOES work if you setopt NO_BARE_GLOB_QUAL.
That you need to use NO_BARE_GLOB_QUAL to avoid having trailing parens
interpreted as glob qualifiers is documented in several other places.
It's wildly impractical to document every possible interaction of the
dozens of tangentially related options at every example.

} How could the fact be included, that this pattern is okay to use in
} the following position?

That's included too, in the sense that glob qualifiers never apply when
you aren't doing file name matching.

Re: confusing passage in zshexpn(1)

[Frank Terbeck]

Bart Schaefer <schaefer@brasslantern.com>:
> On Dec 12,  1:21am, Frank Terbeck wrote:
[...]
> } But the manual suggests that this should work.
> 
> People are WAY too "suggestible."
> 
> Not every fragment that appears as part of a sentence is desgined to be
> usable as a literal stand-alone example! [...]

Yes, I agree. People should not take single sentences from the manual
out of context.

> } How could this be included in the manual?
> 
> As it happens, this fragment DOES work if you setopt NO_BARE_GLOB_QUAL.
> That you need to use NO_BARE_GLOB_QUAL to avoid having trailing parens
> interpreted as glob qualifiers is documented in several other places.
> It's wildly impractical to document every possible interaction of the
> dozens of tangentially related options at every example.
[...]

ACK.
Apparently I should have thought a little more thoroughly before
posting. Sorry.

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925

Re: confusing passage in zshexpn(1)

[Bart Schaefer]

On Dec 12, 12:31pm, Frank Terbeck wrote:
}
} Apparently I should have thought a little more thoroughly before
} posting. Sorry.

No, please don't take it that way.  I apologize if I came off as a bit
of a curmudgeon.

Re: confusing passage in zshexpn(1)

[Peter Stephenson]

Frank Terbeck wrote:
> Hi list,
> 
> Someone on IRC wondered about a problem with the following passage in
> zshexpn(1):
> 
> [snip]
>  x##    (Requires EXTENDED_GLOB to be set.) Matches one or more occur-
>         rences of the pattern x. This operator has high precedence;
>         '12##' is equivalent to '1(2##)', rather than '(12)##'. No
>         more than two active '#' characters may appear together.
> [snap]
> 
> Because of this part of the manual he tried this:
> % setopt EXTENDED_GLOB; touch 12222; echo 1(2##)
> zsh: unknown file attribute
> 
> That's because of the trailing parentheses in the globbing pattern.
> But the manual suggests that this should work.

Well, as Bart pointed out, no it doesn't, it's indicating precedence of
interpretation and nowhere says it's in the form you need to match a
file under every possible circumstance.  But it's easy to add a
cautionary note.

> How could the fact be included, that this pattern is okay to use in
> the following position?
> 
> [snip]
> % file=12222
> % [[ ${file} == 1(2##) ]] && print match.
> match.

Do you mean you're suggesting this as an alternative example that would
actually work?  I think I'll just stick with the warning note---it's
cleaner to write this as 12## anyway, without the parentheses.  That's
why you don't fall over the glob qualifier problem in practice:  you
only need the parentheses when there are #'s after them.

By the way, if you feel yourself susceptible to problems like this,
you can set both NO_BARE_GLOB_QUAL and EXTENDED_GLOB and use (#q...) for
glob qualifiers.

Index: Doc/Zsh/expn.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/expn.yo,v
retrieving revision 1.74
diff -u -r1.74 expn.yo
--- Doc/Zsh/expn.yo	7 Nov 2006 22:47:07 -0000	1.74
+++ Doc/Zsh/expn.yo	12 Dec 2006 10:34:23 -0000
@@ -1504,7 +1504,8 @@
 Matches one or more occurrences of the pattern var(x).
 This operator has high precedence; `tt(12##)' is equivalent to `tt(1(2##))',
 rather than `tt((12)##)'.  No more than two active `tt(#)' characters may
-appear together.
+appear together.  (Note the potential clash with glob qualifiers in the
+form `tt(1(2##))' which should therefore be avoided.)
 )
 enditem()
 subsect(ksh-like Glob Operators)

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

Re: confusing passage in zshexpn(1)

[Frank Terbeck]

Peter Stephenson <pws@csr.com>:
> Frank Terbeck wrote:
[...]
> > That's because of the trailing parentheses in the globbing pattern.
> > But the manual suggests that this should work.
> 
> Well, as Bart pointed out, no it doesn't, it's indicating precedence of
> interpretation and nowhere says it's in the form you need to match a
> file under every possible circumstance.

Yes, that's how I understood it as well in the first place. I thought
the way the person on IRC understood it was reasonable as well. But
it's true that people shouldn't see every sentence as potential
real-life examples.

> But it's easy to add a cautionary note.

Okay. But I hope that won't lead people to demand warning notes for
every little piece of documentation that (treated alone) looks like an
example.

[...]
> > [snip]
> > % file=12222
> > % [[ ${file} == 1(2##) ]] && print match.
> > match.
> 
> Do you mean you're suggesting this as an alternative example that would
> actually work?

No! :-) I just didn't know how to express what I wanted to say
properly.

> [...] it's cleaner to write this as 12## anyway, without the
> parentheses.  That's why you don't fall over the glob qualifier
> problem in practice:  you only need the parentheses when there are
> #'s after them.

Yes, that was my reply on IRC as well. I was just confused and didn't
think close enough before posting.

> By the way, if you feel yourself susceptible to problems like this,
> you can set both NO_BARE_GLOB_QUAL and EXTENDED_GLOB and use (#q...) for
> glob qualifiers.

No, I don't. But thank you anyway. :)

Regards, Frank

-- 
In protocol design, perfection has been reached not when there is
nothing left to add, but when there is nothing left to take away.
                                                  -- RFC 1925