Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: globbing in conditional expressions



On May 14,  4:19am, Daniel Shahaf wrote:
}
} > You could define (via zmodload) an operator that applies filename
} > generation to its argument, but changes to the internals of globbing
} > would be needed to make a short-circuit happen.  Then those changes
} > would have to be exposed somehow so that the operator could use them.
} 
} I've taken a shot at making those changes, see attached.

Interesting!  A few thoughts just reading through the patch:

I'm very curious why you chose to insert a new parameter in the middle
of the globlist() and zglob() signatures, instead of appending it.

The way we'd have typically done this in the past would be to keep the
old call signature as it was and introduce a new entry point with the
new signature, to isolate the changes to as few files as possible.
This also makes it easier to match meaningful changes to the commits
that made them, given that nearly all of the changes in the calls are
not changes of semantics.

(The main body of the old function would become the body for the new
call signature, to which the old signature would then call through.
On the other hand, that does lead to some clutter, so I don't really
feel that strongly either way.)

The strspn(..., "abcdefghkmnoprstuwxzLONGS") probably should NOT have
the "m" added to them, because those are intended to be identifying
operators that are defined by POSIX "test".  It'd be a bit difficult
to use [ -m ... ] anyway because the glob pattern would expand before
the call to the test builtin.

Do I read correctly that "shortcircuit" also means "don't return any
file names, just return an indication of whether there is such a file"
??  (Since you don't allocate the matchbuf array when shortcircuit.)
If so, there might be a more descriptive name for it, "search_only"
or something.

The test [[ -m zero* ]] && [[ ! -m *nonexistent* ]] could be written
[[ -m zero* && ! -m *nonexistent* ]] -- if that doesn't parse (I see
no reason to think it wouldn't) then something is wrong.  Did you
check path searches like **/zero* and whether glob flags work right?

I may give this patch a try tomorrow sometime.



Messages sorted by: Reverse Date, Date, Thread, Author