Smylers wrote: > I just spotted this in the README.Debian that Debian supply with Bash: > > bash does not check $PATH if hash fails > > bash hashes the location of recently executed commands. When a command > is moved to a new location in the PATH, the command is still in the > PATH but the hash table still records the old location. > > For performance reasons bash does not remove the command from the hash > and relook it up in PATH. > > "For performance reasons"?!? > > The only way I can parse that is as claiming it's better to complain 'No > such file or directory' than it is to run the command that the user > asked for (and is in the path) because the former is faster. Really, do > you expect me to buy that? Is that actually going to be useful to > anybody? > > Use 'hash -r' manually or set a bash option: 'shopt -s checkhash'. > > Options make sense when different users genuinely have different > preferences, not to make up for stupidities in your default behaviour.
Optimizing for the error case is hateful. Choosing a faster error that the user must correct manually over a slightly slower DTRT is an extra special hate. That there's no potential performance hit until AFTER IT'S ALREADY CLEAR THE OPTIMIZATION WILL RESULT IN AN ERROR is reserved for the naked, sweaty Dick Cheney having his way with you level of Hell. Of course, as Peter insinuated, I'm sure by now it's been rationalized as a "feature". -- Ahh email, my old friend. Do you know that revenge is a dish that is best served cold? And it is very cold on the Internet!
