Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Unexpected "unknown file attribute" error
- X-seq: zsh-workers 16237
- From: Peter Stephenson <pws@tinky-winky>
- To: zsh-workers@xxxxxxxxxx (Zsh hackers list)
- Subject: Re: Unexpected "unknown file attribute" error
- Date: Mon, 12 Nov 2001 12:28:56 +0000
- In-reply-to: "Bart Schaefer"'s message of "Fri, 09 Nov 2001 01:22:35 GMT." <1011109012235.ZM14884@xxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
Bart Schaefer wrote:
> For obscure reasons, one of the machines I use at work has this function
> in root's .zshrc:
>
> function add-dir {
> which=$1
> shift
> foreach dir ($*) {
> eval $which=(\${$which} \$dir)
> }
> }
>
> This used to work in 3.0.x, but now that I've installed 4.0.4, it fails with
>
> add-dir:4: unknown file attribute
>
> Why isn't the space inside the parens enough to keep them from being treated
> as a glob qualifier? It used to be.
I think the change is in haswilds() --- so it affects whether globbing
takes place at all, not just qualifiers. It used to check whether there
were balanced parentheses with interesting-looking characters inside; now
it is triggered just by an open parenthesis.
The change is beyond the reach of CVS, but it may have changed to support
patterns like `foo|bar' in case statements --- they used to get wrapped by
an extra layer of parentheses, but now don't; simplifying the code may
have seemed the easiest bet.
Apart from the annoyance of the incompatibility, I don't see why unquoted
parentheses shouldn't trigger globbing, though --- it saves a lot of rather
picky tests which are hard to keep in line with the main globbing code.
--
Peter Stephenson <pws@xxxxxxx> Software Engineer
CSR Ltd., Science Park, Milton Road,
Cambridge, CB4 0WH, UK Tel: +44 (0)1223 392070
Messages sorted by:
Reverse Date,
Date,
Thread,
Author