Re: hash not restored after running command -p

[Mike Jonkmans]

On Sun, Oct 31, 2021 at 08:36:49PM +0300, Oğuz wrote:
> On Sun, Oct 31, 2021 at 7:07 PM Mike Jonkmans <bashbug@jonkmans.nl> wrote:
> >
> > On Sun, Oct 31, 2021 at 05:23:03PM +0200, Oğuz wrote:
> > > 31 Ekim 2021 Pazar tarihinde Mike Jonkmans <bashbug@jonkmans.nl> yazdı:
> > > >
> > > > Using the hash as alias for commands, that are not in your PATH,
> > > > seems risky though.
> > >
> > > Why? Risky how?
> >
> > Risky, mostly on a cognitive level.
> >
> > 'command -p foo' doesn't look like it has a side effect.
> 
> How does a command look like it has side effects?

Changing PATH would be well known to have side effects.
Also, i wouldn't be surprised of '/bin/rm -rf /bin' influencing things.

> > E.g. assume you have /usr/local/bin/foo and /bin/foo
> >         PATH=/usr/local/bin
> >         command -p foo
> >         foo
> >
> > You would not think that /bin/foo is executed for foo, given the value of 
> > PATH.
> 
> I suppose I would not, because the manual doesn't say `command -p' has
> this effect. I'll give you that.

POSIX is also silent on this.

> > It could also lead to bugs.
> > E.g.
> >         PATH=/usr/local/bin
> >         source script
> >         foo
> >
> > When the 'command -p foo' is introduced in the sourced script, foo changes.
> 
> Yes, that's how `source' works; contents of the sourced file alters
> the sourcing application's execution environment. In addition to
> calling `command -p foo', if the sourced file changes `PATH', or
> defines a function named `foo', or enables `expand_aliases' and
> defines an alias named `foo', `foo' 'changes'.

Note that it is not always the same person writing the code.
The script might be written/changed by someone unaware of the side effects.
I assume script writers would know about PATH and alias effects,
less so about 'hash' and even fewer people would know about 'command -p'.

--
Regards, Mike Jonkmans