compatibility issue in environment-modules version 4.1.1-1
gunnarhj at ubuntu.com
Wed May 8 00:40:38 UTC 2019
Hi again, Gösta!
I do not know how environment-modules is thought to work, but I did a
small test to figure out the starting point with sourcing the
The first line in that file reads:
shell=$(/usr/bin/basename $(/bin/ps -p $$ -ocomm=))
I put that line in a temporary .sh file in /etc/profile.d on my machine,
and let it print the contents of the $shell variable.
* Doing a graphical login using LightDM made $shell be assigned the
value "lightdm-session" (the script which sources files in
/etc/profile.d is /usr/sbin/lightdm-session).
* Doing a graphical login using GDM made $shell be assigned the value
"Xsession" (the script which sources files in /etc/profile.d is
* Logging in to a TTY made $shell be assigned the value "bash".
This means that in case of graphical logins, modules.sh will always pick
/usr/share/modules/init/sh for initialization. Its design is apparently
not thought for the kind of sourcing by the display manager which
happens on Ubuntu (and Ubuntu based) systems.
I suppose (not tested, though) that one way to work around this is to
edit modules.sh so it sources /usr/share/modules/init/bash by default
instead of /usr/share/modules/init/sh . Your initial solution, i.e.
making the /bin/sh symlink point to bash instead of dash, is another way.
At this time I don't think that my initial theory (editing
/usr/sbin/lightdm-session) makes a difference.
If you find that editing modules.sh as I suggested fixes the issue, I'd
say that we have nailed the cause of the problem. modules.sh seems to be
a Debian invention, so in that case I'd suggest that you report it
there. Hopefully the Debian maintainer is willing to make modules.sh a
bit more intelligent. :)
More information about the Ubuntu-devel-discuss