The (e) glob qualifier and NO_NOMATCH

The (e) glob qualifier and NO_NOMATCH

[Bart Schaefer]

It occurs to me that, unlike most of the other glob qualifiers, (e:cmd:)
doesn't necessarily need any existing filename on which to operate.

Consider by comparison _path_files in the completion code, which includes
a hack to force auto-mounting.  Wouldn't it be nice to be able to write a
function "forcemount" that matches a pattern against /etc/hosts or NIS
and mounts all those filesystems?  Then you could use

  for remote in /net/r*(+forcemount); do ...

This currently doesn't work, because once "r*" fails to match anything
in /net, the qualifiers are ignored and the entire string is returned as
the result.  Instead we'd need to call "forcemount" with REPLY set to
the path segment pattern "r*".

Unfortunately it looks like this would need a pretty large reworking of
the globbing code.  The original source string of path segment patterns
isn't kept around anywhere that I immediately see, and NO_NOMATCH is
handled only after the entire scan has completed.  Further, qualifiers
don't seem to have the order-dependence that one might expect:

  print *(e:'reply=(${REPLY}x)':/)

first finds all directories and then appends "x" to their names, rather
than failing entirely because there are no directories having the names
that result after appending an x to an existing name, and

  print *(e:'reply=(${REPLY}x)':e:'reply=(${REPLY}y)':)

does not produce names with "xy" appended, only with "y".

For the time being, I guess this is just food for thought.

-- 

Re: The (e) glob qualifier and NO_NOMATCH

[Oliver Kiddle]

Bart wrote:
> Consider by comparison _path_files in the completion code, which includes
> a hack to force auto-mounting.  Wouldn't it be nice to be able to write a
> function "forcemount" that matches a pattern against /etc/hosts or NIS
> and mounts all those filesystems?  Then you could use
> 
>   for remote in /net/r*(+forcemount); do ...
> 
> This currently doesn't work, because once "r*" fails to match anything
> in /net, the qualifiers are ignored and the entire string is returned as
> the result.  Instead we'd need to call "forcemount" with REPLY set to
> the path segment pattern "r*".

The main thing that makes (e) useful is that it runs the function once
for each matched file. forcemount presumably is something that only
needs to run once because the parameter you want to pass is an
unexpanded pattern.

Given that you can do something like:

  for remote in $(forcemount '/net/r*'); do ...

is your point purely that you think the syntax would be nice or are you
thinking in terms of being able to pass the function down through the
completion system so that it is only run if and when _path_files expands
the pattern?

> don't seem to have the order-dependence that one might expect:
> 
>   print *(e:'reply=(${REPLY}x)':/)

In many respects using (e) and modifying $reply makes it more of a
modifier than a qualifier. Perhaps we should have had a :e modifier.

> For the time being, I guess this is just food for thought.

You might also find it interesting to look at the trick I used in
_subversion for tricking globbing into generating files that don't
exist. It does the following:

  _files -g ".svn(/e:_svn_deletedfiles:)"

The use of .svn as the file is largely irrelevant. This works better
than the similar functionality in _cvs because the rest of
_file/_path_files is used). It isn't perfect due to the fact that the
fake files can't have type information associated with them.

Oliver

Re: The (e) glob qualifier and NO_NOMATCH

[Bart Schaefer]

On Jun 22,  4:12pm, Oliver Kiddle wrote:
}
} Given that you can do something like:
} 
}   for remote in $(forcemount '/net/r*'); do ...
} 
} is your point purely that you think the syntax would be nice or are you
} thinking in terms of being able to pass the function down through the
} completion system so that it is only run if and when _path_files expands
} the pattern?

I was just using the completion system as an example of a case where a
nonexistent file is forced to come into existence so it can later be
globbed.  I'm not otherwise thinking in terms of completion at all.

Rather I'm thinking in terms of the "search upwards but stop at the
first file" glob request posted to zsh-users earlier this week.  I
wanted to say

  up() { reply=( (../)#$~REPLY(Odon) ); reply=( $reply[1] ) }

  less adr*(+up)

but "up" is never called because adr* has no matches in the current dir.
 
} In many respects using (e) and modifying $reply makes it more of a
} modifier than a qualifier. Perhaps we should have had a :e modifier.

We already do, it just doesn't mean "eval" ....

Re: The (e) glob qualifier and NO_NOMATCH

[Oliver Kiddle]

Bart wrote:
> Rather I'm thinking in terms of the "search upwards but stop at the
> first file" glob request posted to zsh-users earlier this week.  I
> wanted to say
> 
>   up() { reply=( (../)#$~REPLY(Odon) ); reply=( $reply[1] ) }
> 
>   less adr*(+up)

The closest I can think of that you can get to this is something like
the following:
  up() { print -r "(../)#$1(Odon[1])" }
  alias up='noglob up'

  less ${~$(up adr*)}

That's not much easier to type but it might make more sense to allow
something like $~(up d*) to work than to add a glob qualifier that
alters the pattern.

In the case of the actual searching upwards problem, I've wondered in
the past whether some actual syntax would make sense. I mostly use it
for getting to Ant build.xml files and have considered using bindkey -s
so that something like '.**/' would expand to '(../)#'. A new syntax
could perhaps work a little differently than '(../)#' to avoid needing
(Odon[1]) or ([-1]). Stopping at the first directory that produces a
match is probably enough (searching up from .. to / not down from / to
..).

Oliver