... and how do I reset it ?

Hi,

I'm currently experimenting with firejail. It's a tool that can put applications in a sandbox. It comes with lots of predefined profiles for standard applications like firefox (hence the name), geany, meld, ...

However, I'm not happy with some of the profiles, e.g. for geany (a text editor) and meld (a diff/merge tool). I'm still learning to configure firejail, but in the meantime I prefer to disable it for those applications. Disabling works by removing a symlink from /usr/local/bin. During my experiments, I'm removing and re-adding the symlink back and forth.

( For those who are interested in more detail, the symlink points to /usr/bin/firejail, which in turn checks with which name it was called, then reads the corresponding profile, and starts the application with the same name in a sandbox. )

And here comes the problem:
Once bash had found e.g. meld in /usr/local/bin (the symlink), it will only look for it it there. If I remove the symlink try to start meld, bash will complain about /usr/local/bin/meld not found. But the original is still in /usr/bin. And $PATH is /usr/local/bin:...:/usr/bin:... so I thought it should work.
At least says
Does bash remember where it once found "meld" and refuse other locations from that moment on ?
And is there a way to make it forget that location (other than starting a new shell) ?

Bash will keep a history of the interactive session. See "man bash" for the built-in command history and the file ~/.bash_history in the section "SHELL BUILTIN COMMANDS" and the whole section "HISTORY"

Also look at the content of the environment variable $PATH. It is described in the manual page's sub section "Shell Variables".

I don't think it's about the history. I did not start meld including the path (like /usr/local/bin/meld) but only typed "meld", so the history only contains "meld".
To my undrstanding, typing "meld" (without any path) again should search the whole $PATH but it doesn't.

As I wrote in my original post, $PATH contains /usr/local/bin as well as /usr/bin.

which uses $PATH
If which finds the executable, it’s in the PATH.

Ah. I understand now. I'm not sure of a solution, but I see that when an executable disappears or is moved, Bash keeps looking for it in the old location rather than re-checking $PATH for it. This might be a bug.

I am guessing that the BASH_CMDS variable might be involved and that the shell built-in command hash might be of help.

I would say this is the usual cache problem: commands are cached to be able to find and execute them faster, but sometimes the cache will be outdated....

Short answer is yes. It's called hashing and it is designed to speed things up. But it's quite easy to switch it off. Just give the command

1 members found this post helpful.

The "hash" command is listed under the Bourne/POSIX built-in section, so is not Bash specific (nobody actually said it was, but I somehow made that assumption).


In addition to the mentioned "set +h" there is also a "shopt checkhash" option that appears to be subtly different:

From those descriptions, it sounds like the latter might maintain some performance benefits of avoiding path lookups, though I'm not sure there'd be a noticeable difference for most scripts, unless PATH happens to be really long and/or reference a slow filesystem.

1 members found this post helpful.

aaah ... hash ... OK :-)

worked.

Thanks a lot. :-)

or I'd think for loop that's run a million times?

Back in the day before even Perl was a normal thing, a lot of 'glue' was written using $<shell>, so on an old school prod box, that (hash) would have been beneficial in getting the work done noticeably faster.

That quote wasn't referring to three decades ago, and was contrasting "-h" and "checkhash", not the hash command.

Most shell scripts don't even loop a million times, never mind needing to deal with disappearing/moving commands during that looping.

I'd be curious about any current real-world script that does do such looping, but still has a reason to be written in shell...?