#1144635 zsh: broken by the FPATH environment variable defined by bash / lmod

Package:
zsh
Source:
zsh
Description:
shell with lots of features
Submitter:
Vincent Lefevre
Date:
2026-08-24 16:35:02 UTC
Severity:
normal
Tags:
#1144635#5
Date:
2026-08-17 13:09:57 UTC
From:
To:
On a machine that has just been upgraded to trixie, I start zsh
via a bash login shell (run by sshd). The issue is that when it
is a login shell, bash defines the $FPATH environement variable
to '/usr/share/lmod/lmod/init/ksh_funcs' as shown by

  echo "FPATH = '$FPATH'" >&2

at the beginning of the ~/.bash_profile file, which outputs:

FPATH = '/usr/share/lmod/lmod/init/ksh_funcs'

This is possibly due to /usr/share/lmod/8.7.60/init/bash from the
lmod package, as mentioned at

https://github.com/direnv/direnv/issues/858

(note that I'm not a direnv user... this was found by Google + AI).

Such a setting completely breaks zsh, which outputs

zsh:1: url-quote-magic: function definition file not found

each time I type a key (the key has no other effect, i.e. the
command line at the prompt remains empty, so I need to type Ctrl-D
to quit zsh).

It appears that instead of ignoring the $FPATH environment variable
on startup, zsh sets $fpath to $FPATH.

Note that the zshparam(1) man page says: "Some environment variables
are not imported for reasons of security or because they would
interfere with the correct operation of other shell features.",
which should be the case here.

#1144635#10
Date:
2026-08-17 14:35:32 UTC
From:
To:
severity 1144635 important
thx

* Vincent Lefevre [Mon Aug 17, 2026 at 03:09:57PM +0200]:

Github is currently down
(https://www.githubstatus.com/incidents/zkxwbgr0cnmx),
so I can't check that reference.

But is it actually necessary and a good idea, that lmod
*exports* variables like that?

It looks like lmod pollutes the environment quiet a lot,
like e.g. also:

  LMOD_SETTARG_FULL_SUPPORT=no
  LMOD_VERSION=8.7.60
  MODULEPATH_ROOT=/usr/share/modulefiles
  LMOD_PKG=/usr/share/lmod/lmod
  LMOD_ROOT=/usr/share/lmod
  BASH_ENV=/usr/share/lmod/lmod/init/bash
  LMOD_sys=Linux
  MODULEPATH=/etc/lmod/modules:/usr/share/lmod/lmod/modulefiles/
  LMOD_CMD=/usr/share/lmod/lmod/libexec/lmod
  BASH_FUNC_ml%%=() {  eval "$($LMOD_DIR/ml_cmd "$@")"
  }
  BASH_FUNC_module%%=() {  if [ -z "${LMOD_SH_DBG_ON+x}" ]; then
   case "$-" in
   *v*x*)
   __lmod_sh_dbg='vx'
   ;;
   *v*)
   __lmod_sh_dbg='v'
   ;;
   *x*)
   __lmod_sh_dbg='x'
   ;;
   esac;
   fi;
   if [ -n "${__lmod_sh_dbg:-}" ]; then
   set +$__lmod_sh_dbg;
   echo "Shell debugging temporarily silenced: export LMOD_SH_DBG_ON=1 for Lmod's output" 1>&2;
   fi;
   eval "$($LMOD_CMD shell "$@")" && eval "$(${LMOD_SETTARG_CMD:-:} -s sh)";
   __lmod_my_status=$?;
   if [ -n "${__lmod_sh_dbg:-}" ]; then
   echo "Shell debugging restarted" 1>&2;
   set -$__lmod_sh_dbg;
   fi;
   unset __lmod_sh_dbg;
   return $__lmod_my_status
  }

Right.

Do you mind brining this up to upstream yourself?

regards
-mika-

#1144635#17
Date:
2026-08-17 17:32:22 UTC
From:
To:
Control: forwarded -1 https://www.zsh.org/mla/workers/2026/msg00939.html

I don't think it really matters anyway.

Probably not. IMHO, the right solution would be to ask lmod users
to run something like "source ..." from their own init file.

Moreover, while I don't know what lmod's FPATH-related code should
do, it does not seem to behave as intended:

unset __zsh_fpath
if [ -n "${ZSH_VERSION+x}" ] &&  ! (autoload -U compinit && compinit -C 2> /dev/null) ; then
  __zsh_fpath=$(unset FPATH; zsh -f -c 'echo $FPATH')
fi
export FPATH=$(/usr/share/lmod/lmod/libexec/addto --append FPATH ${__zsh_fpath:-$FPATH} /usr/share/lmod/lmod/init/ksh_funcs)
unset __zsh_fpath

The goal of the


I've posted a message to zsh-workers and put the URL in "forwarded".

#1144635#24
Date:
2026-08-17 20:26:56 UTC
From:
To:
* Vincent Lefevre [Mon Aug 17, 2026 at 07:32:22PM +0200]:

Yes, IMO that's wrong behavior of lmod.

Thanks, appreciated.

I agree with what Eric replied in
https://www.zsh.org/mla/workers/2026/msg00940.html:

| if bash learned about FPATH and autoloadable functions, then like other shell variables,
| it shouldn't be exported (without good reason) and that file is the problem.

(and further)

I'd suggest we re-assign this to lmod?

regards
-mika-

#1144635#29
Date:
2026-08-24 11:54:22 UTC
From:
To:
Control: reassign -1 lmod 8.7.60-1
Control: notforwarded -1

I think that there may still be issues with FPATH since this
is not standardized (some Fortran compilers may use such an
environment variable). But since this will not change in zsh,
I'm reassigning it (anyway, this is at least a bug in lmod).

Since there have been at least 2 changes in the code upstream
related to the FPATH setting in bash

https://github.com/TACC/Lmod/commit/9e5be80e07cd7c66d2652898d17f407a3d8fed9f
https://github.com/TACC/Lmod/commit/d92570fb5b9fb33d27731042fcb212e11f3fa4f1

I don't know whether upstream is still affected. But I would
say that it is still broken since FPATH is still exported.

#1144635#44
Date:
2026-08-24 16:32:11 UTC
From:
To:
I opened a new bug

https://github.com/TACC/Lmod/issues/853

but it eventually got closed with the reason: "The latest version
of Lmod doesn't have this problem. Either upgrade your site to the
latest or install the latest Lmod in your account."