On 6/13/2017 9:47 AM, Zack Weinberg wrote: > On Tue, Jun 13, 2017 at 9:45 AM, Jeffrey Walton <noloa...@gmail.com> wrote: >> On Tue, Jun 13, 2017 at 8:40 AM, Zack Weinberg <za...@panix.com> wrote: >>> On Tue, Jun 13, 2017 at 8:29 AM, Jeffrey Walton <noloa...@gmail.com> wrote: >>>> >>>> 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. -- Earnie _______________________________________________ Autoconf mailing list Autoconf@gnu.org https://lists.gnu.org/mailman/listinfo/autoconf
