whence (was Re: local unfunction)

whence (was Re: local unfunction)

[Bart Schaefer]

On Sat, Mar 31, 2018 at 7:58 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:
> On 30/03/18 10:23 PM, Bart Schaefer wrote:
>>
>> Try adding -w to get whence to tell you which hash table it's reading
>> from.
>
>  $ which -mwa zsh
> zsh: command
> zsh: command
> zsh: command
>
> ... I had looked at that but the output doesn't seem to say anything useful.

Firstly, "which" isn't the same as "whence" although it should become
equivalent if -w is present.

However, that's not the same thing that produced unexpected results
before; you've added -a and removed the wildcard from "zsh*".  I meant
to retry all three, but in particular this one:

% whence -wm "zsh*"

Re: whence (was Re: local unfunction)

[Ray Andrews]

On 31/03/18 08:25 AM, Bart Schaefer wrote:
> % whence -wm "zsh*"

$ whence -wm "zsh*"
zsh: command
zsh5.3: command        # binary
zsh5.3:: command        # text file

... I've yet to understand what the point of the '-w' switch is. I dunno 
Bart, it seems I'm the only guy who has issues with whence so perhaps I 
shouldn't belabour all this but it seems riddled with bugs to me. '-m' 
and '-a' seem to fight each other and the results are inconclusive.  
whence is important, one needs to know what is going to be executed when 
one types a command, these ifs and buts are frustrating.  My wrapper 
around whence is approaching 300 lines, and it's only purpose is to give 
one-stop shopping for what, it seems to me, whence should do anyway:

-a # keep looking after the first match (the one to be executed) is found

-m # find all matches of a pattern, subsumes '-a'  (executable ONLY 
unless ... )

-t # Show non executable (text?) files as well, obviates -a, subsumes 'm'.

-s, -S  # Expand links, even if found on 'dot' on the path.

So: 'whence -mts "zsh*" ' ... would give me one stop shopping for 
anything that is either directly executable or sourcable via path search 
(which zsh does anyway).  '-a' is actually redundant:

$ whenz zsh # Command that will be executed.

$ whenz -m zsh # Keep searching. (no pattern but so what, keep searching 
anyway.)

$ whenz -m "zsh*" # Keep searching and match the pattern too (because 
one is given).

$ whenz -mt "zsh*" # As above, but match non executables on the path as 
well.

$ whenz -mtS "zsh*" As above but show link chains, even on the 'dot', 
even on Tuesdays.

Logical?

Re: whence (was Re: local unfunction)

[Bart Schaefer]

On Sat, Mar 31, 2018 at 10:21 AM, Ray Andrews <rayandrews@eastlink.ca> wrote:
>
> $ whence -wm "zsh*"
> zsh: command
> zsh5.3: command        # binary
> zsh5.3:: command        # text file

What's with the extra ":" there?  Is there actually a colon in the file name?

> ... I've yet to understand what the point of the '-w' switch is.

% zsh() { print nope }
% alias zsh='print not this either'
% whence -w zsh
zsh: alias
% whence -wa zsh
zsh: alias
zsh: function
zsh: command
%

> -a # keep looking after the first match (the one to be executed) is found

So far so good.

> -m # find all matches of a pattern, subsumes '-a'  (executable ONLY unless
> ... )

No, this does not subsume -a, because it will only return hits from
the internal hash tables.  Thus if you have a file named "zsh" in 3
different directories in $path, the command hash table will contain
only the first of those, and whence -m will find only that one.
However, if you have three differently-named files matching "zsh*" in
$path, they will all have separate entries in the command hash table,
and whence -m will list all three.

> -t # Show non executable (text?) files as well, obviates -a, subsumes 'm'.

This being a proposed new flag.  I think this points to the source of
the confusion.  The command hash table will contain the first
occurrence of every file name from every directory in $path, even if
that first occurrence is not executable, and "whence -m" will show you
all of the matching entries in the hash table.  The existing -m option
subsumes your -t.

The other confusion is that -m never searches $path.  It always
populates the command hash table if necessary and then searches the
hash table.

% path=(./Src $path)
% whence zsh
./Src/zsh
% whence -a zsh
./Src/zsh
/bin/zsh
% whence -m zsh
/bin/zsh
%

There's one magic side-effect of combining -a and -m, which is that -m
will find something in the hash table and then -a will search $path
for what was found.  That's a result of re-using the code that walks
the path to do the output formatting for the names found by -m.

Re: whence (was Re: local unfunction)

[Ray Andrews]

On 31/03/18 06:18 PM, Bart Schaefer wrote:
>
> What's with the extra ":" there?  Is there actually a colon in the file name?
It's deliberate abuse, I tried all sorts of things to see what might 
work and what might break.  It seems there's nothing in my issues 
that's  directly caused by some sort of weird naming .
> -m # find all matches of a pattern, subsumes '-a' (executable ONLY unless 

I meant it might be so not that it is so.
> This being a proposed new flag.  I think this points to the source of
> the confusion.  The command hash table will contain the first
> occurrence of every file name from every directory in $path, even if
> that first occurrence is not executable, and "whence -m" will show you
> all of the matching entries in the hash table.  The existing -m option
> subsumes your -t.
>
> The other confusion is that -m never searches $path.  It always
> populates the command hash table if necessary and then searches the
> hash table.
I dunno Bart, it all seems so counter intuitive.  Maybe it's just me, 
but my 'interpretation' seems the natural one.  It seems absolutely 
robust as far as aliases and functions and everything but files, but 
with files, one never knows what might be found.  At the very least the 
docs could be a bit more clear.  But as I said, I seem to be the only 
one chaffing about this so I'll use other means to find matching files 
on the path and make a clear distinction between executables and non 
executables.  The output of my wrapper, unverbose, looks like this:

$ i "zsh*"

146:: (1)TYPE: /aWorking/Zsh/Source/Wk/zsh is an unexecutable script or 
text file
146:: (2)TYPE: /aWorking/Zsh/System/zsh is an unexecutable script or 
text file
146:: (3)TYPE: /aWorking/Bin/zsh5.3.txt is an unexecutable script or 
text file
196:: (1)TYPE: zsh is /usr/local/bin/zsh -> /aWorking/Bin/zsh5.3:
196:: (2)TYPE: zsh is /usr/bin/zsh -> /aWorking/Bin/zsh5.3:
196:: (3)TYPE: zsh is /bin/zsh -> /aWorking/Bin/zsh5.3:

... it finds every damn thing every time no buts or maybes and I'm 
expecting it to work in April too except when the moon is waning ;-)

$ i grep

196:: (1)TYPE: GREP is an alias for grep $g_nocase --color=auto:
196:: (2)TYPE: grep is /bin/grep:

$ i echo

196:: (1)TYPE: echo is a shell builtin:
196:: (2)TYPE: echo is /bin/echo:

Re: whence (was Re: local unfunction)

[Daniel Shahaf]

Bart Schaefer wrote on Sat, 31 Mar 2018 18:18 -0700:
> The other confusion is that -m never searches $path.  It always
> populates the command hash table if necessary and then searches the
> hash table.
> 
> % path=(./Src $path)
> % whence zsh
> ./Src/zsh
> % whence -a zsh
> ./Src/zsh
> /bin/zsh
> % whence -m zsh
> /bin/zsh
> %

So, -m can lie if 'rehash' hasn't been run since $PATH was last changed?
I'm having trouble seeing why this is useful behaviour.

(Yes, 'rehash' could be expensive, but even so, why does -m give
outdated results as opposed to just erroring out?)

Re: whence (was Re: local unfunction)

[Bart Schaefer]

On Sun, Apr 1, 2018 at 10:33 AM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> So, -m can lie if 'rehash' hasn't been run since $PATH was last changed?

It forces a cmdnamtab->filltable() before scanning, so I think not.

Re: whence (was Re: local unfunction)

[Daniel Shahaf]

Bart Schaefer wrote on Sun, Apr 01, 2018 at 11:17:40 -0700:
> On Sun, Apr 1, 2018 at 10:33 AM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >
> > So, -m can lie if 'rehash' hasn't been run since $PATH was last changed?
> 
> It forces a cmdnamtab->filltable() before scanning, so I think not.

Let me rephrase.  In your example:

> > > % path=(./Src $path)
> > > % whence zsh
> > > ./Src/zsh
> > > % whence -a zsh
> > > ./Src/zsh
> > > /bin/zsh
> > > % whence -m zsh
> > > /bin/zsh
> > > %

why do 'whence' and 'whence -m' give different results?  Isn't one or the other
wrong?

Re: whence (was Re: local unfunction)

[Bart Schaefer]

On Wed, Apr 4, 2018 at 11:10 AM, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Let me rephrase.  In your example:
>
>> > > % path=(./Src $path)
>> > > % whence zsh
>> > > ./Src/zsh
>> > > % whence -a zsh
>> > > ./Src/zsh
>> > > /bin/zsh
>> > > % whence -m zsh
>> > > /bin/zsh
>> > > %
>
> why do 'whence' and 'whence -m' give different results?  Isn't one or the other
> wrong?

It could be argued that "whence -m" is inaccurate, yes, but that's
because "." and other relative locations in $PATH are weird, not
because the command hash table is out of date.

It's important to note that "whence -m" is doing pattern matching on
strings, not filename generation.  It's not meant to search for files
in $PATH, it's meant to do "hash -m ..." for all possible
command-position hash tables in one go.  Most of what else it does, it
does because somebody complained that every line of output wasn't
uniformly formatted.

Re: whence (was Re: local unfunction)

[Ray Andrews]

On 04/04/18 05:20 PM, Bart Schaefer wrote:
>
> It's important to note that "whence -m" is doing pattern matching on
> strings, not filename generation.  It's not meant to search for files
> in $PATH, it's meant to do "hash -m

But what is the real world relevance of 'hash -m'?  From almost the 
beginning of my experience with Linux and zsh one has the need to know 
what " $ [command] ENTER " is likely to do, especially in tricky 
situations where there  are scripts and aliases and links and functions 
and builtins and files that might share the same name.  One is pointed 
to whence as the utility that answers that question, but it does not 
answer it accurately when it comes to files.  One way or another, the 
dot directory is simply mishandled, I think that's inescapable.  And the 
other strange things might seem rational as far as the hash table goes, 
but they sure aren't rational as far as using whence for what everyone 
says it is supposed to do and which it almost does do except for the 
anomalies -- find things that execute.  Perhaps whence should be left as 
a curiosity and another builtin developed that does what I think whence 
should do and what needs to be done -- show everything executable named 
[PATTERN] ... all the time.  The pie can be sliced into three clearly 
understandable, non overlapping pieces: 1) Non-file stuff: aliases, 
builtins, etc. 2) Executable files and links on the path.  3) Non 
executable files on the path that zsh will search for in case of " $ 
source [name] ".  Patterns matched if patterns supplied.  Throw in a few 
verbosity levels and that's that.  It could be so simple.

Re: whence (was Re: local unfunction)

[Bart Schaefer]

On Apr 4,  6:41pm, Ray Andrews wrote:
}
} On 04/04/18 05:20 PM, Bart Schaefer wrote:
} >
} > It's important to note that "whence -m" is doing pattern matching on
} > strings, not filename generation.  It's not meant to search for files
} > in $PATH, it's meant to do "hash -m
} 
} But what is the real world relevance of 'hash -m'?

Forty-two?

Seriously, "hash -m" exists because somebody in the past 25 years found
it useful to search the hash tables, and "whence -m" exists because
"hash -m" does and somebody else thought that if anything has a "search
the tables" option then everything should have a "search the tables"
option (which is also why "typeset -m" exists ... in fact I've lost
track of which chicken laid which egg).

Re: whence (was Re: local unfunction)

[Ray Andrews]

On 04/04/18 10:08 PM, Bart Schaefer wrote:
> Forty-two?
>
> Seriously, "hash -m" exists because somebody in the past 25 years found
> it useful to search the hash tables, and "whence -m" exists because
> "hash -m" does and somebody else thought that if anything has a "search
> the tables" option then everything should have a "search the tables"
> option (which is also why "typeset -m" exists ... in fact I've lost
> track of which chicken laid which egg).
Ha!  I love these historical anecdotes.  But what we peasants need is a 
whence that does what God in his love wants it to do for us namely show 
us commands.  Even on the dot, even on Tuesday, even if the sum of the 
ascii values of the characters in the command is a prime number.  All 
the matches, all the time.  It really is unhelpful that -m and -a trip 
over each other.  It's Gnostic. Should switches ever do that?  Nope, 
either one subsumes the other, or one cancels the other, or they have 
entirely separate and complementary outputs.  Logically speaking we have 
a union minus the negation of an intersection.  Obscure.
>