The $SHELL environment variable is not automatically updated by the shell itself because it is inherited from the parent process, typically the login session or the terminal emulator. Upgrading zsh changes the executable on disk but does not retroactively modify the environment variables of existing sessions. To see the correct path to your new zsh binary, you must restart your login session or explicitly export the variable in your configuration files.
Why $SHELL Remains Unchanged
When a user logs into a Linux system, the display manager or SSH daemon sets the
$SHELL variable based on the entry in
/etc/passwd. This variable is passed down to all child processes, including the initial shell instance. If you upgrade zsh from version 5.7.1 to 5.9 by compiling it from source or installing it via a package manager, the binary location may change (for example, from
/bin/zsh to
/usr/local/bin/zsh). However, the running shell process retains the value it was given at startup. It does not query the operating system for its own current executable path and update the variable accordingly.
This behavior is intentional. The
$SHELL variable represents the user's default login shell as defined by the system administrator, not necessarily the path of the currently executing binary. Many scripts and tools rely on this variable to determine which shell to invoke for non-interactive commands. Changing it dynamically within a session could break assumptions made by those external tools. Therefore, seeing an old path in
$SHELL after an upgrade is expected behavior until the session is refreshed or the variable is manually corrected.
Verifying Your Current Zsh Path
Before modifying any configuration, it is crucial to verify exactly where your new zsh installation resides. The
$SHELL variable might be misleading if it points to a symlink or an older version still present in your
$PATH. You can determine the actual path of the zsh binary that will be executed when you type
zsh by using the
which or
type command.
Run the following command in your terminal:
which zsh
Or for more detailed information about how the shell resolves the command:
type -a zsh
If the output shows
/usr/local/bin/zsh, then your new version is correctly installed and accessible. If it still shows
/bin/zsh, your
$PATH variable might be prioritizing the old location, or the new binary has not been added to the standard search paths. Ensure that
/usr/local/bin appears before
/bin in your
$PATH environment variable. You can check your current path order with
echo $PATH.
Updating the Configuration Files
To ensure consistency across new sessions, you should update your shell initialization files. The most common file for zsh is
~/.zshrc. Adding an explicit export statement here guarantees that every time a new zsh instance starts, it knows its correct location.
Open your
~/.zshrc file in a text editor and add the following line, replacing the path with the one you found in the previous step:
export SHELL="/usr/local/bin/zsh"
After saving the file, you need to reload the configuration for the changes to take effect in the current terminal. Run:
source ~/.zshrc
Now, checking
echo $SHELL should display the new path. This method ensures that any scripts spawned from this shell will also receive the correct
$SHELL value. For a permanent fix that survives reboots, you may also want to update the
/etc/passwd file to reflect the new default shell, although this is often handled by system utilities like
chsh.
Checking System Default Shell Settings
Sometimes, the discrepancy arises because the system-wide default shell has not been updated. The
/etc/passwd file contains the default login shell for each user. If you use
getent passwd $USER, you can see what the system thinks your default shell is. If it still points to the old binary, future logins will inherit that old path.
You can update your default shell using the
chsh command:
chsh -s /usr/local/bin/zsh
This command updates the relevant entry in
/etc/passwd. Note that this change only affects new login sessions. Existing terminals will continue to use the old value until they are closed and reopened. Additionally, some desktop environments or terminal emulators cache the default shell setting. If you are using a GUI terminal, you might need to configure it explicitly to launch
/usr/local/bin/zsh instead of relying on the system default.
For more insights into how shell initialization files are processed, you might find it helpful to read about
Understanding the Order of Shell Source Files. This knowledge helps in troubleshooting why certain variables might be overwritten later in the startup sequence.
Handling Related Environment Issues
Upgrading shells can sometimes lead to compatibility issues with other environment variables or completion systems. If you encounter errors related to
.zcompdump files after the upgrade, it is likely due to version mismatches between the old completion system and the new zsh binary. In such cases, removing the stale dump file and letting zsh regenerate it is the standard solution. You can learn more about fixing these specific errors in our guide on
Fix Error: Can't Open File $HOME/.zcompdump in Zsh.
It is also worth noting that some applications rely on
$SHELL to determine how to spawn sub-shells. If you have custom scripts that parse this variable, ensure they are robust enough to handle different paths. Dynamic updates to
$SHELL within a running session are generally discouraged unless absolutely necessary, as they can confuse debugging tools and logging mechanisms that track process ancestry.
Frequently Asked Questions
Does changing $SHELL affect my current session?
No, exporting a new value for
$SHELL only affects child processes started after the change. It does not alter the identity of the currently running shell process. To fully apply the change, you should start a new terminal window or tab.
Why does my terminal emulator still open the old zsh?
Terminal emulators often have their own settings for the "Login Shell" or "Command" field. If this is hardcoded to the old path, it will ignore the system default and your
$SHELL variable. Check your terminal preferences to ensure the executable path matches your new zsh installation.
Can I use $ZSH instead of $SHELL?
While
$ZSH exists in some contexts, it is not a standard POSIX variable and is less widely supported than
$SHELL. Most external tools and scripts expect
$SHELL to point to the user's default shell. Using
$SHELL is the recommended approach for portability.
What if I don't have root access to update /etc/passwd?
You can still manage the variable within your user space by exporting it in
~/.zshrc or
~/.profile. This ensures that your interactive sessions and any scripts launched from them use the correct path, even if the system default remains outdated.
Will upgrading zsh break my aliases and functions?
Generally, no. Zsh maintains backward compatibility across minor versions. However, if you have complex custom configurations, it is wise to test them in a new session after the upgrade. If you face issues with completions, refer to resources on
Disabling Command Substitution in zsh to troubleshoot potential conflicts in your setup.