FPATH gets carried to ZSH when using bash, even when SUPPORT_KSH is set to "no"

[surak]

On

Lmod/init/bash.in

Line 28 in de1b731

export FPATH=$(@PKGV@/libexec/addto FPATH @PKGV@/init/ksh_funcs)

Using bash, I get

echo $FPATH
/usr/lmod/lmod/init/ksh_funcs

Which messes up with zsh prompts, for example, because they use the same variable for their stuff.

Many supercomputer users load zsh on top of bash, as they can't change the default shell set up by the sysadmins. So the FPATH gets carried away to ZSH and breaks stuff there, as you know already.

Interestingly, even when SUPPORT_KSH is set to no, the change happens.

[rtmclay]

As you may know, the issue is that both Zsh and Ksh use FPATH but not in the same way. The other issue is that some bash users run ksh scripts. Sites can control the default state at configure time by setting --with-supportKsh=no. This will of course disable support for bash users running ksh scripts that have module commands.

The change that I have made is that those bash users can add :

export SUPPORT_KSH=no

to their startup script so that when they start zsh, lmod change FPATH.

You can test this yourself by adding:

if [ -z "${SUPPORT_KSH}" ]; then
  SUPPORT_KSH="@support_ksh@"
fi

at line 26 in init/bash.in and then re-install Lmod.

Note that bash users can also unset FPATH in their bash startup scripts

At TACC we do allow for user to choose their shell either bash, zsh or tcsh if that is of any help.

This change has been checked-in to the master branch if you want to test it.

Thanks very much for the but report!

[rtmclay]

O.K. to close this issue?

[surak]

Thanks for the reply.

Ir’s interesting that a change which can break zsh, which is being favored more recently, in favor of ksh, which is not becoming more popular, is an opt-out instead of opt-in.

How about the opposite? Where one set explicitly that wants to use ksh. That seems more sustainable in the long term, as less people will need this.
What do you think?

[rtmclay]

I agree that Zsh is a better shell. It is my shell on all the systems I have access to. The trouble is many of the weather codes use ksh scripts and we have to support them. Those will change very slowly. But I don't control whether this is the default or not. Sites do.

In fact the unconfigured value for --with-supportKsh is no and has always been. So someone at your site has decided to support KSH scripts. That is outside my control.

Also KSH script are not supported if the user's startup shell is zsh. Over time, HPC sites should support zsh as it is getting more popular since Mac have made it their default shell.

Also if you are having your bash startup scripts start zsh then you are already a sophisticated user and you can clear FPATH or set SUPPORT_KSH=no in your startup scripts before "exec zsh".

I have added a section to the Lmod FAQ to remind bash->zsh users about the FPATH issue.

[surak]

In fact the unconfigured value for --with-supportKsh is no and has always been. So someone at your site has decided to support KSH scripts. That is outside my control.

Interestingly not. I got this on a new cluster I’m assembling, it doesn’t have climate models yet. But fine, if you say that’s the default, I won’t be bugging you. And as now I know how to fix things, it’s fine. We can close this one.

[rtmclay]

There was a mistake in the bash startup script. Current it has:

if [ $SUPPORT_KSH = yes -o -n "${SSH_CLIENT+x}" -o -n "${KSH_VERSION+x}" ]; then
  if [ -z "${ZSH_VERSION+x}" -a -z "${__LMOD_SET_FPATH+x}" ]; then
    export FPATH=$(@PKGV@/libexec/addto FPATH @PKGV@/init/ksh_funcs)
    export __LMOD_SET_FPATH=1
  fi
fi

Since just about everyone is connecting over SSH, this means that every bash user is ignoring $SUPPORT_KSH. In the next Lmod release this block code becomes:

if [ $SUPPORT_KSH = yes -o -n "${KSH_VERSION+x}" ]; then
  if [ -z "${ZSH_VERSION+x}" -a -z "${__LMOD_SET_FPATH+x}" ]; then
    export FPATH=$(@PKGV@/libexec/addto FPATH @PKGV@/init/ksh_funcs)
    export __LMOD_SET_FPATH=1
  fi
fi

[surak]

Awesome! Thanks a lot!