Re: 'whence' question

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Nov 5,  6:00pm, Peter Stephenson wrote:
} Subject: Re: 'whence' question
}
} On Wed, 05 Nov 2014 18:49:23 +0100
} Oliver Kiddle <okiddle@xxxxxxxxxxx> wrote:
} > Looking at the source, it seems that whence doesn't support both -a and
} > -m together though it doesn't produce an error.
} 
} You're right: I think *that's* a bug.

Hmm.  This is more complicated than it at first appears.

The -a option is O(n*c) where n is $#path and c is $#argv, because it
merely has to glue the two arrays together and test whether each of
the resulting strings is an executable file path.  (I discount the
cost of one hash lookup for each hash table.)

The -m option currently is O(h*c) where h is the size of all the hash
tables, plus (one time only) the cost of filling the command table if
it hasn't already been.

To do "whence -am" the "right way" would also be approximately O(h*c)
because we have to compare every file in every directory in $path to
the list of patterns (and h is a fair estimate of that number of
files).  However, I'm not sure what the "right way" *is*, because:

The pattern accepted by the -m option is not a glob, it's a pattern of
the string-matching variety.  If we were to simply glue each of the
arguments onto the end of each $path directory and glob the resulting
cross-product, the wrong results could be returned.  Furthermore, for
e.g. cygwin, the filled hash table has dealt with mapping "foo.exe"
onto "foo" with the suffix case-insensitive, so even a string match
against the file names across $path could be wrong.

Having just written that, it occurs to me that perhaps the "right way"
is the equivalent of this? --

	whence -a ${(k)commands[(I)pattern]}