Re: When a hashed pathname is deleted, search PATH

[Mike Frysinger]

On Tue 18 Mar 2014 21:11:07 Linda Walsh wrote:
> Mike Frysinger wrote:
> > On Tue 18 Mar 2014 01:04:03 Linda Walsh wrote:
> >> 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?
> > 
> > as soon as you talk about trying to time something, you're obviously
> > looking at it wrong.  having a system that only works when the cpu/disk
> > is fast and idle is a waste of time and bad for everyone.
> 
> ---
> 
> Um... this is a User Interface involving humans, and you are looking
> for something that needs to be 100%?  If this was a reactor control
> program, that's one thing, but in deciding what solution to implement to
> save some small lookup time or throw it away, an 90% solution is
> probably fine.  It's called a heuristic.  AI machines use them.
> Thinking people use them.  Why should bash be different?

except now you have useless knobs users don't want to deal with, and now your 
solution is "sometimes it works, sometimes it doesn't, so really you can't 
rely on it and you have to go back to the same system you've been using all 
along".  trotting out other systems (like defense in depth) doesn't change the 
fact that your idea is flaky at best and is entirely user visible (unlike 
defense in depth strategies).

i already highlighted a technical way of solving it 100% of the time.
-mike

signature.asc
Description: This is a digitally signed message part.