For example in 4.3 when direxpand is enabled, `cd ./tmpTAB' 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. Could we keep the 4.2 behavior?
-clark
On 3/14/14 2:39 AM, Clark Wang wrote:
For example in 4.3 when direxpand is enabled, `cd ./tmpTAB' 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.
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.
--
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 hashed path and do
On 14 March 2014 18:23, Chet Ramey chet.ra...@case.edu 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: No
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. Why is it not the
