On 3/17/14 4:38 PM, Reuben Thomas wrote:
> On 17 March 2014 20:30, Chet Ramey <chet.ra...@case.edu
> <mailto:chet.ra...@case.edu>> wrote:
>
> On 3/17/14 10:17 AM, Dave Rutherford wrote:
> > On Mon, Mar 17, 2014 at 10:12 AM, Chet Ramey <chet.ra...@case.edu
> <mailto:chet.ra...@case.edu>> wrote:
> >> On 3/15/14 2:44 PM, Reuben Thomas wrote:
> >>> On 15 March 2014 18:23, Chet Ramey <chet.ra...@case.edu
> <mailto:chet.ra...@case.edu>
> >>> <mailto:chet.ra...@case.edu <mailto:chet.ra...@case.edu>>> wrote:
> >>> Is there a downside to making checkhash the default?
> >>
> >> Only the minor performance hit it would extract on every command
> lookup.
> >
> > Only on commands that were found in the hash table, correct?
>
> Yes, of course. I should have said every *successful* command hash table
> lookup. This is much less of an issue now than when the option was first
> added.
>
>
> OK, I misread the description, and thought it would only look the command
> up if the execution fails. Why can't that be done?
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.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
