hash -r versus type -a: Choosing a strategy to avoid stale Bash command cache after PATH updates
0 reputation · 27 Sept 2023, 23:20 UTC
0 reputation · 27 Sept 2023, 23:20 UTC
The goal is to guarantee that Bash resolves commands using the updated PATH immediately after a modification, without returning stale paths from its internal hash table.
Two documented strategies exist: running hash -r to purge the entire hash table, which ensures fresh lookups but may cause a temporary performance hit as the table is rebuilt; or invoking type -a or command -v to bypass the hash cache on each call, which avoids the reset overhead but adds a modest per‑invocation cost.
The trade‑off depends on how often PATH is altered in a session and how many commands are executed thereafter, making it unclear which method minimizes total overhead or if one approach is preferable in specific workflows.
Which method results in lower cumulative latency when PATH is changed once per session and dozens of commands follow? Does the one‑time cost of hash -r outweigh the repeated overhead of type -a/command -v? Are there scenarios where bypassing the hash is unsafe or ineffective?
34775 reputation · 28 Sept 2023, 07:04 UTC
When you modify PATH once in a Bash session and then run dozens of external commands, the most efficient way to avoid stale entries is to run hash -r once immediately after the change. hash -r clears the per‑shell hash table, forcing the next execution of each command to perform a fresh PATH lookup. The one‑time cost of rebuilding the table is outweighed by the repeated per‑invocation overhead that would be incurred if you prefixed every command with type -a or command -v.
hash -r Winshash -r is resolved by a single PATH scan, and the result is cached.type -a / command -v Are Usefulhash -r for ensuring that subsequent bare commands use the new PATH.PATH in the current shell.
export PATH=/new/dir:$PATH
hash -r
PATH again, then reuse the result.hash -r Is Not SufficientPATH change, that subshell has its own hash table and must run hash -r itself.PATH.Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 28 Sept 2023, 02:10 UTC
When evaluating the cumulative latency of hash -r versus repeated type -a or command -v calls, it is important to distinguish between lookup complexity and execution overhead.
hash -r: This is a one-time O(1) operation to clear the table. While the first call to any command after the reset triggers a linear scan of the PATH, subsequent calls to that same command return to O(1) lookup speed.type -a / command -v: These force a linear scan of the PATH every time they are invoked. If used as a wrapper for every command, you replace a cached lookup with a repeated O(N) search (where N is the number of directories in your PATH).In a standard interactive session (Bash 4.0+), the one-time cost of hash -r is negligible. The repeated overhead of bypassing the cache is significantly higher when executing dozens of commands, especially if the PATH includes slow network mounts or a large number of entries.