Re: When a hashed pathname is deleted, search PATH

Chris Down wrote: You don't use heuristics when you have access to the underlying mechanisms, that's an extremely poor way to program, and an extremely good way to accrue technical debt. -- Mike Frysinger wrote: as soon as you talk about trying to time something, you're obviously looking at

Re: When a hashed pathname is deleted, search PATH

Linda Walsh wrote: Sure, you could forget the timing part -- and have bash check for every child, it's reason for exiting and if ENOENT, then check whatever path the child was just spawned with if you wanted a general solution for a low-incident problem. It would still be better than havin

Re: When a hashed pathname is deleted, search PATH

Chris Down wrote: Linda Walsh writes: 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 the

Re: When a hashed pathname is deleted, search PATH

Mike Frysinger wrote: i already highlighted a technical way of solving it 100% of the time. -mike Wasn't that the method of incurring the existence check for all executions in the parent to check for the rare case that a hashed image that a child was about to execute didn't exist AND the

Re: When a hashed pathname is deleted, search PATH

Linda Walsh writes: > 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 > shoul

Re: When a hashed pathname is deleted, search PATH

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 pare

Re: When a hashed pathname is deleted, search PATH

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

Re: When a hashed pathname is deleted, search PATH

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 h

Re: When a hashed pathname is deleted, search PATH

On 18 March 2014 08:04, 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 has

Re: When a hashed pathname is deleted, search PATH

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 f

Re: When a hashed pathname is deleted, search PATH

On 17 March 2014 20:46, 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. > Thanks for the explanation. -- http://rrt.sc3d.org

Re: When a hashed pathname is deleted, search PATH

On 3/17/14 4:38 PM, Reuben Thomas wrote: > On 17 March 2014 20:30, Chet Ramey > wrote: > > On 3/17/14 10:17 AM, Dave Rutherford wrote: > > On Mon, Mar 17, 2014 at 10:12 AM, Chet Ramey > wrote: > >> On 3/15/14 2:44 PM, Reuben

Re: When a hashed pathname is deleted, search PATH

On 17 March 2014 20:30, Chet Ramey wrote: > On 3/17/14 10:17 AM, Dave Rutherford wrote: > > On Mon, Mar 17, 2014 at 10:12 AM, Chet Ramey > wrote: > >> On 3/15/14 2:44 PM, Reuben Thomas wrote: > >>> On 15 March 2014 18:23, Chet Ramey >>> > wrote: > >>> Is there a down

Re: When a hashed pathname is deleted, search PATH

On 3/17/14 10:17 AM, Dave Rutherford wrote: > On Mon, Mar 17, 2014 at 10:12 AM, Chet Ramey wrote: >> On 3/15/14 2:44 PM, Reuben Thomas wrote: >>> On 15 March 2014 18:23, Chet Ramey >> > wrote: >>> Is there a downside to making checkhash the default? >> >> Only the minor

Re: When a hashed pathname is deleted, search PATH

On 3/17/14 10:19 AM, Reuben Thomas wrote: > 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? Not exactly, since it requires a check of every ha

Re: When a hashed pathname is deleted, search PATH

On 17 March 2014 14:12, Chet Ramey wrote: > On 3/15/14 2:44 PM, Reuben Thomas wrote: > > On 15 March 2014 18:23, Chet Ramey > > wrote: > > > > It's not been a problem, really. The existence of the `checkhash' > option > > has been enough. How often do you re

Re: When a hashed pathname is deleted, search PATH

On Mon, Mar 17, 2014 at 10:12 AM, Chet Ramey wrote: > On 3/15/14 2:44 PM, Reuben Thomas wrote: >> On 15 March 2014 18:23, Chet Ramey > > wrote: >> Is there a downside to making checkhash the default? > > Only the minor performance hit it would extract on every command l

Re: When a hashed pathname is deleted, search PATH

On 3/15/14 2:44 PM, Reuben Thomas wrote: > On 15 March 2014 18:23, Chet Ramey > 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

Re: When a hashed pathname is deleted, search PATH

On 15 March 2014 18:23, Chet Ramey 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. Since bash is h

Re: When a hashed pathname is deleted, search PATH

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 3/14/14, 6:14 PM, Eric Blake wrote: > So the three ways to reset a hash without resorting to the non-portable > shopt are 'hash -r', 'PATH=$PATH', or causing lookup to fail - but bash > is not honoring the third way by default (I didn't test if bas

Re: When a hashed pathname is deleted, search PATH

On 3/14/14, 6:05 PM, Reuben Thomas wrote: > On 14 March 2014 18:23, Chet Ramey > wrote: > > On 3/14/14 12:11 PM, Reuben Thomas wrote: > > Tested in bash 4.3. > > > > $ foo > > ... a command is run > > $ hash > > hits command > >0 /ho

Re: When a hashed pathname is deleted, search PATH

On 03/14/2014 04:05 PM, Reuben Thomas wrote: >>> Why doesn't bash just remove the hashed path and do a normal PATH >> search? I >>> have to remove it manually. >> >> Look at the description of the `checkhash' option to `shopt'. It does what >> you want; it's just not the default. >> > > Thanks.

Re: When a hashed pathname is deleted, search PATH

On 14 March 2014 18:23, Chet Ramey wrote: > On 3/14/14 12:11 PM, Reuben Thomas wrote: > > Tested in bash 4.3. > > > > $ foo > > ... a command is run > > $ hash > > hits command > >0 /home/rrt/bin/foo > > $ rm `which foo` > > $ which foo > > /usr/bin/foo > > $ foo > > bash: /home/rrt/bin/foo:

Re: When a hashed pathname is deleted, search PATH

On 3/14/14 12:11 PM, Reuben Thomas wrote: > Tested in bash 4.3. > > $ foo > ... a command is run > $ hash > hits command >0 /home/rrt/bin/foo > $ rm `which foo` > $ which foo > /usr/bin/foo > $ foo > bash: /home/rrt/bin/foo: No such file or directory > > Why doesn't bash just remove the hashe

When a hashed pathname is deleted, search PATH

Tested in bash 4.3. $ foo ... a command is run $ hash hits command 0 /home/rrt/bin/foo $ rm `which foo` $ which foo /usr/bin/foo $ foo bash: /home/rrt/bin/foo: No such file or directory Why doesn't bash just remove the hashed path and do a normal PATH search? I have to remove it manually. --