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. --

Re: direxpand in 4.3 is different from in 4.2

On 3/14/14 2:39 AM, Clark Wang wrote: > For example in 4.3 when direxpand is enabled, `cd ./tmp' would be > expand `./tmp' to the full path (e.g. `/root/tmp/'). I think this is not > good especially when the full dir path is very long. Bash 4.2 (tested with > 4.2.37) does not behave like this. Coul