Re: hash -d 0/1 and other hash stuff

[Mike Jonkmans]

On Mon, Sep 11, 2023 at 03:25:01PM -0400, Chet Ramey wrote:
> On 9/6/23 10:55 AM, Mike Jonkmans wrote:
> > The following 'hash -d' statements have different exit statuses.
> > 
> >     bash --noprofile --norc -c \
> >             'hash -d ls; echo $?' ## 0
> >     bash --noprofile --norc -c \
> >             'cat </dev/null; hash -d ls 2>/dev/null; echo $?' ## 1
> It's whether the hash table is empty. `hash -d' shortcuts if the hash
> table is empty, but I agree that it should not.

Was the supplied patch ok?

> > Questions
> > 
> > 1) Why is 'hash -d x' exiting with 1 at all? If the goal is to `unhash x',
> > 'hash -d x' will do the job. Even if x was not hashed at all.
> The parallel is with `unalias', which does the same thing if the alias
> being removed isn't in the alias table.

It is certainly useful to see a warning message (in case of typos).
Changing the exit status to 0 may not be worth the trouble.

> > 2) 'hash x' and 'hash -l x' seem to do the same
> Yes. The `-l' option is an output format modifier; it takes -t to print
> the hashed commands.

It does not take -t per se, see `hash -l'.

The `hash' and `hash -l' output are different, though.
Adding a name should keep these differences.

> > 'hash -lt x' outputs what I would have expected 'hash -l x' to do.
> > Note that 'hash -lt x' doesn't add x to the hash (unexpected).
> The `-t' option says to list the contents of the hash table; the `-l'
> option modifies the output format.

Yet `hash -t' errors, while `hash -l' lists all.
Instead `hash -t' could be made to iterate over all names in the hashtable
(prepending the name, even if there is only one command). No error on empty.

`help hash' states 
        hash: hash [-lr] [-p pathname] [-dt] [name ...]
        ...
        -l        display in a format that may be reused as input
        ...
        -t        print the remembered location of each NAME, ...
        Arguments:
      NAME      Each NAME is searched for in $PATH and added to the list
                of remembered commands.

This leaves open the question as to whether NAME is added in case of -t.

In the synopsys, what does the separate placement of [-lr] and [-dt] mean?

> > 3) These option combinations should error/exit 1:
> Agreed, except for
> >     hash -p path -t name
> which is valid, if ambiguous. `hash' prioritizes -t over -p in this case.

Why would you want to make an exception for -t?

> > This adds name, using path, but ignores the other option:
> >     hash -p path -l name
> Because it's not listing output, and -l is an output modifier.
> >     hash -p path -d name
> This is, again, ambiguous, and hash prioritizes -p over -d.
> > Using -t ignores -d:
> >     hash ls; hash -td ls
> Ambiguous; hash prioritizes -t over -d.
> > And -d ignores -l:
> >     hash ls; hash -ld ls
> Because -l is an output format modifier.

It is the current implementation doing the prioritizing.
Nowhere is this prioritization mentioned.

I don't think that any option should be ignored.
Nor should ambiguous commands be executed.
An immediate exit, signals the developer to, get coffee, read the manual,
and fix their code.
Which presupposes that the manual is correct ;)

-- 
Regards, Mike Jonkmans