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. Could we keep the 4.2 behavior? This isn't accurate. When you build bash-4.3 with the default options, and choose to enable direxpand using shopt, you get the same behavior as in bash-4.2. In particular, relative paths aren't expanded to full paths. If, on the other hand, you build bash with the enable-direxpand-default configuration option, you do get this behavior. I left the relative-path expansion option enabled when bash is built this way. In retrospect, I should probably have left it out. If you prefer it disabled, you can change the assignment to dircomplete_expand_relpath in bashline.c. That is not to say there aren't problems with relative paths and completion in bash-4.3, but they aren't with direxpand. Additionally, I'm not talking about the situation when bash-completion is included in the mix. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
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. -- http://rrt.sc3d.org
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 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. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
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: 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. > > 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 default? Shouldn't an optimisation (hashing PATH lookup) be transparent to the user by default? -- http://rrt.sc3d.org
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. Why is it not the default? Shouldn't an optimisation (hashing PATH > lookup) be transparent to the user by default? > For that matter, POSIX requires the 'checkhash' behavior: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#set http://pubs.opengroup.org/onlinepubs/9699919799/utilities/hash.html http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01 In particular: "Once a utility has been searched for and found (either as a result of this specific search or as part of an unspecified shell start-up activity), an implementation may remember its location and need not search for the utility again unless the PATH variable has been the subject of an assignment. If the remembered location fails for a subsequent invocation, the shell shall repeat the search to find the new location for the utility, if any." 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 bash in 'set -o posix' behaves differently). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
