Chet Ramey wrote:
Because the execution fails in a child process. You'd be able to fix it for that process, but would do nothing about the contents of the parent shell's hash table. The way the option works now is to check the hash lookups and delete anything that is no longer an executable file, then redo the lookup and hash the new value.
---- Wouldn't bash notice that the child exited in <.1 seconds ( or is it less? I.e. if bash spawns a child for an exec and gets a sigchild from it < (some small value of time) later, THEN it could check the path that was just executed ??? That would keep any side performance hits to a rather small number of cases with relatively few false positives. The up side is the delay in the parent would only happen AFTER a command has been attempted, and immediately failed. I think a further lookup in the parent should happen in < 1ms given that the path lookup just happened in the child and most OS's would have cached the path lookup when the child did it. I.e. - the parent would have next to zero delay in rewalking a "hot" path.
