Maybe the subject is a bit misleading, I will clarify it.
Bash is using hash table to remember locations of executed commands. Whenever you try to run a command bash looks in hash table. When the command is found in table then bash will you full path name as it is in the table.
However there is a problem when the command moved (or is deleted). Bash by default is not checking if the command is really on the location. But there is bash option that will force bash to check if the command really exists. Man page says: checkhash If set, bash checks that a command found in the hash ta‐ ble exists before trying to execute it. If a hashed command no longer exists, a normal path search is per‐ formed.
I have a question, if it is worth to enable this option by default? It will not confuse some people, but can increase disk searching. Comments welcome.
RR
On 08/19/2011 01:24 PM, Roman Rakus wrote:
I have a question, if it is worth to enable this option by default? It will not confuse some people, but can increase disk searching. Comments welcome.
Confusion can only happen in this particular case, I think: 1) you run a command and the cache is populated 2) you delete the command 3) you try to run the command again, in the same shell 4) you expect bash to find the command in another path, but get an error instead Correct me if I'm wrong.
I remember having had to use "hash -r" one or two times in my life for this kind of issues.
RR
Hey, I'm RR too. :-)
2011/8/19 Roberto Ragusa mail@robertoragusa.it
On 08/19/2011 01:24 PM, Roman Rakus wrote:
I have a question, if it is worth to enable this option by default? It will not confuse some people, but can increase disk searching. Comments welcome.
Confusion can only happen in this particular case, I think:
- you run a command and the cache is populated
- you delete the command
- you try to run the command again, in the same shell
- you expect bash to find the command in another path, but get an error instead
Correct me if I'm wrong.
I remember having had to use "hash -r" one or two times in my life for this kind of issues.
Not worth it, one can always use which to verify if command is gone or is bash is going mad. (It happened to me one, I used yum remove with -y and didn't expect one dependency).
RR
Hey, I'm RR too. :-)
Well, does MM count?
-- Greetings, Maciej Małecki
On Fri, Aug 19, 2011 at 01:24:37PM +0200, Roman Rakus wrote:
I have a question, if it is worth to enable this option by default? It will not confuse some people, but can increase disk searching. Comments welcome.
How can it increase disk searching in case the program is still there? It needs to be fetched from the disk anyhow when it is run. Or am I missing something here?
Regards Till
2011/8/20 Till Maas opensource@till.name:
How can it increase disk searching in case the program is still there? It needs to be fetched from the disk anyhow when it is run. Or am I missing something here?
It's just one stat with every command execution. If you're curious how it looks internally, findcmd.c:71 and findcmd.c:327. Function which gets executed is file_status, defined in findcmd.c:84. -- Greetings, Maciej Małecki
Roman Rakus wrote:
Maybe the subject is a bit misleading, I will clarify it.
Bash is using hash table to remember locations of executed commands. Whenever you try to run a command bash looks in hash table. When the command is found in table then bash will you full path name as it is in the table.
However there is a problem when the command moved (or is deleted). Bash by default is not checking if the command is really on the location. But there is bash option that will force bash to check if the command really exists. Man page says: checkhash If set, bash checks that a command found in the hash ta‐ ble exists before trying to execute it. If a hashed command no longer exists, a normal path search is per‐ formed.
I have a question, if it is worth to enable this option by default? It will not confuse some people, but can increase disk searching. Comments welcome.
It will only help if the first match in the search path is removed, it will still not do the right thing if a new match is prepended to the search path.
IMHO, this whole hashing should not be done in interactive shells at all. The bottleneck is going to be the user running the commands anyway. I can see how it speeds up scripts, but it's just confusing and useless in interactive operation.
Kevin Kofler