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

[Chet Ramey]

On 9/12/23 8:28 AM, Mike Jonkmans wrote:
> 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?

Yes, thanks.


> > > 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'.

Well, that's true: hash with no name arguments prints the contents of the
hash table, and `hash -l' with no name arguments prints the contents in a
different output format.

> The `hash' and `hash -l' output are different, though.

Exactly.

> Adding a name should keep these differences.

No. Once you add a name argument without the -t option, you're adding
commands to the hash table.

> > > '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.

See above. You're correct that `hash -t' requires NAME arguments to
display.

> 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.

It could, but hash without options does that already.

> `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.

It isn't.

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

They are the options that require NAME arguments.

> > > 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?

What exception?

> It is the current implementation doing the prioritizing.

This is a meaningless statement: it's always the implementation that does
the prioritizing.

> Nowhere is this prioritization mentioned.
>
> I don't think that any option should be ignored.
> Nor should ambiguous commands be executed.

I think it's better to do something useful.


--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/