Why doesn't Autotools makefile update Bash hash cache after install?

[Jeffrey Walton]

Hi Everyone,

After performing a 'make install', the Bash shell could still use the
old program because the Bash hash cache was not updated for the
program. 'which' will show the expected program (say
/usr/local/bin/foo), but running 'foo' will result in the old program
(say /usr/bin/foo).

The results can be reproduced with a simple 'configure && make && sudo
make install'. There's nothing special going on. In fact, I suspect
this is probably the most common use case.

Why does Autotools produce a makefile which does _not_ update the
cache under Bash shells?

Jeff

[Zack Weinberg]

Post by Jeffrey Walton
Why does Autotools produce a makefile which does _not_ update the
cache under Bash shells?

It can't. The rehash operation has to be done in the shell that is
the parent process of 'make install' (and any other shell processes
that are running at the time); there is no way for 'make install' to
do that.

zw

[Zack Weinberg]

Post by Zack Weinberg

Post by Jeffrey Walton
Why does Autotools produce a makefile which does _not_ update the
cache under Bash shells?

It can't. The rehash operation has to be done in the shell that is
the parent process of 'make install' (and any other shell processes
that are running at the time); there is no way for 'make install' to
do that.

Thanks, makes sense.
I understand its a bad interaction. Things should "just work", but
they don't. Would you happen to know why Bash does not update on its
own after a 'make install'?

How is Bash to know that some random command changed the contents of
the directories in PATH? Nowadays, I suppose it could use
inotify/dnotify/whatever the current flavor of that is to find out,
but in the past there was no such mechanism.

zw

[Earnie]

Post by Zack Weinberg

Post by Zack Weinberg

Post by Jeffrey Walton
Why does Autotools produce a makefile which does _not_ update the
cache under Bash shells?

It can't. The rehash operation has to be done in the shell that is
the parent process of 'make install' (and any other shell processes
that are running at the time); there is no way for 'make install' to
do that.

Thanks, makes sense.
I understand its a bad interaction. Things should "just work", but
they don't. Would you happen to know why Bash does not update on its
own after a 'make install'?

How is Bash to know that some random command changed the contents of
the directories in PATH? Nowadays, I suppose it could use
inotify/dnotify/whatever the current flavor of that is to find out,
but in the past there was no such mechanism.

And let's not forget that autotools is about portability and cannot use
bashisms as bash may not be the shell. The fact that you install a new
version of a binary and expect your current environment to use it on
systems that cache what is being used is just misguided expectations.
On any *nix system a deleted file is only deleted to the user interface
but still exists until all open channels close it. It is the reason you
cannot delete an active file and expect it to relieve a filesystem usage
overrun. The file is still active and the inodes will not be released
until the processes with open channels to it have closed. Often a
reboot is the only way to relieve that issue. On Windows, you cannot
delete an opened file, if you try you will get an error from the system.