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.
