Shell:Hooks

lastmod 2026-09-04created 2026-09-041 edits

Shell Hooks are a mechanism that intercepts the execution flow of a shell (Bash, Zsh, etc.) so that specific scripts or environment variable changes run automatically when the user enters a command or changes directory.

Runtime version management and environment variable management tools such as mise, asdf, pyenv, and direnv build a dynamic environment using this Hook system and the Shim paradigm, instead of physically interrupting the shell process.

Overview

To instantly switch the version of a tool (e.g., Node.js 18 -> 20) when entering a specific directory in a shell environment, the shell's state (mainly the $PATH environment variable) must be changed dynamically. The two core mechanisms that implement this are Hooks and Shims.

Mechanism 1: Shell Hooks

Shell hooks use the shell's built-in features to run a specific function or command just before the prompt is printed to the screen. This is the approach mainly adopted by modern tools (mise, direnv, etc.) for better performance.

How it is implemented

• Bash: uses the PROMPT_COMMAND environment variable. Commands registered in this variable run every time just before the shell displays $PS1 (the prompt).
• Zsh: uses the precmd hook function.

Execution flow

1. The user changes directory with the cd command.
2. The command finishes and the shell tries to draw a new prompt on the screen.
3. Just before drawing the prompt, the hook registered in PROMPT_COMMAND (or precmd) (e.g., _mise_hook) runs in the background.
4. The hook function scans the configuration files in the current directory (mise.toml, .envrc, etc.).
5. Once the required tool version is determined, it injects (Export) the path of that version's actual binary at the top of the current shell session's $PATH.
6. When the user types node, the original binary of that version runs immediately, without any interception.

Pros and cons

• Pros: runtime execution is very fast, because each command runs the actual binary directly (Direct) without going through an intermediate script.
• Cons: each shell (Bash, Zsh, Fish, etc.) implements hooks differently, so tool developers must write a separate support script for each shell.

Example (Bash)

# ~/.bashrc 에 추가되는 전형적인 훅 설정 (mise의 경우)
eval "$(mise activate bash)"

# 내부적으로 설정되는 PROMPT_COMMAND의 형태
PROMPT_COMMAND="_mise_hook; $PROMPT_COMMAND"

Mechanism 2: the Shims paradigm

A general-purpose approach used by traditional version management tools (asdf, pyenv, rbenv, etc.). Instead of extending the shell's features, it relies on the operating system's $PATH search priority.

How it is implemented

A specific directory (e.g., ~/.local/share/mise/shims/) is permanently registered at the very front (priority 1) of the $PATH environment variable, and inside it are created fake executables (Shim scripts) with the same names as all the tools the user has installed.

Execution flow

1. The user enters the node command.
2. The shell searches $PATH in order and runs the first Shim file it finds (.../shims/node).
3. Internally, the Shim script calls the version management tool (the main program) and queries, "Based on the current directory, where is the path of the real original binary to run?"
4. Once the correct version is found, the Shim script uses the exec command to replace the process with the real binary (Forwarding), completing execution.

Pros and cons

• Pros: works anywhere $PATH can be set, regardless of the shell type (Bash, Zsh, Fish, etc.). (Excellent compatibility)
• Cons: every time the user enters a command, there is overhead of running the Shim script -> calling the main program -> computing the path -> running the original, which makes execution slightly slower.

Comparison of how major tools work

See also

• Korean: 환경 변수
• Bash
• Zsh
• Shell
• Linux
• Environment Management