Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Is this an old behavior? I would think ENOENT would invalidate the cache entry at least.


It's still a thing in bash 5.2.37.

It's just how bash works. If there's an entry in the session cache, it uses it. Since executable paths only get cached when you run a command successfully, this only happens when it gets moved from one directory in your PATH to another after you run it once, which isn't that common.

Setting PATH or calling hash -r will clear the session cache or one could run set +h which will disable it altogether.


> this only happens when it gets moved from one directory in your PATH to another after you run it once

It also happens when you have two executables in different directories and then you delete the one with the higher priority. Happens regularly for me after I uninstall a Linux Homebrew package.


Isn't cache invalidation one of the hard problems?


Sure but not doing it on ENOENT suggests they’re just being completely lazy. Not to mention that they do have the tools (eg inotify watches) to proactively remove stale entries based on HD changes. Of course I’d be careful about the proactive one as it’s really easy to screw things up more (eg 100 bash instances all watching the same PATH directories might get expensive or forgetting to only do this for interactive mode connected to a TTY)


Retested with bash 5.2.37(1)-release from Debian testing, it still does this :(

Changing $PATH does wipe it at least.


Not working, as intended




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: