Initialize zsh for Non-interactive Jobs
Each shell available to users has its own rules for run-time setup. This affects which files are read in different contexts; interactive, batch, and ssh commands use different files depending on the shell being used. For example, zsh (Z shell) does not initialize like bash, and when ssh launches a shell, the environment for bash users and zsh users is different. For bash users, this means that the modules command is available for remotely executed commands, and for zsh users it is not available.
Users of zsh may find that bash scripts executed as part of batch scheduled jobs do not have the same environment as the login node they are submitted from because they are invoked on non-local MOM nodes. As a result, some commands that work interactively outside of the job script may fail when the batch scheduler tries to invoke the job script. In the context of ssh commands under zsh, only one type of file from two possible locations is read: the zshenv file. To enable the job script to operate, users with accounts on the remote machine can make changes to ~/.zshenv on the remote machine. If the system administrator believes that all users should automatically have a change made, the contents of /etc/zshenv can be modified by a site-local Ansible play.
- method 1
- Export an environment variable that will enable bash scripts (like the job script) to include the module command when the script starts. To enable bash scripts to execute with modules for zsh users as they would for bash users, append the following line to the zshenv file:
export BASH_ENV=/etc/bash.bashrc.local
- method 2
- Modify zsh initialization to always execute interactive startup code every time zsh is launched. To force every zsh shell to perform the startup that an interactive zsh shell does, append the following line to the zshenv file:
source /etc/zshrc