compatibility issue in environment-modules version 4.1.1-1

[Gunnar Hjalmarsson]

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 
/etc/profile.d/modules.sh file.

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
   /etc/gdm3/Xsession).

* 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. :)

-- 
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj