On 17 March 2014 14:12, Chet Ramey <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>> wrote: > > > > It's not been a problem, really. The existence of the `checkhash' > option > > has been enough. How often do you remove binaries in directories in > $PATH? > > > > > > Fairly often: I frequently rename or retire scripts in my per-user bin > > directory. > > OK. Based on the number of reports in the last few years, you are in the > minority. >
It's a minor annoyance, I bet a lot of users just live with it. I'm an inveterate reporter of minor annoyances, and even I took many years to report this problem. To my mind that doesn't indicate it shouldn't be fixed: minor annoyances can easily be "rounded down" to zero, but the total pain can still be large. Only the minor performance hit it would extract on every command lookup. > I don't understand, surely it only has a performance impact when a hashed file or a directory on PATH is (re)moved? How about removing both pain *and* complexity: I'd happily prepare a patch to make checkhash always on, remove its documentation, but of course keep the option name supported for backwards compatibility. Then no-one ever need think about it again. Failing that, I'd also happily prepare a patch to simply switch the default to on. -- http://rrt.sc3d.org
