SV: compatibility issue in environment-modules version 4.1.1-1

[Gösta Ljungdahl]

Hi, Gunnar,


Tested editing /etc/profile.d/modules.sh to source /usr/share/modules/init/bash by default i.e. commented out the line


. /usr/share/modules/init/sh


and put in


. /usr/share/modules/init/bash


but it was not sufficient. Apparently dash comes in at a later stage.


Cheers,

Gösta

________________________________
Från: Gösta Ljungdahl
Skickat: den 8 maj 2019 11:26:29
Till: Gunnar Hjalmarsson; ubuntu-devel-discuss at lists.ubuntu.com
Ämne: SV: compatibility issue in environment-modules version 4.1.1-1


Hi, Gunnar!


No. I doubt that modules.sh is a Debian invention. A file with the exact same content lives in the subdirectory .../init/ of the installation if done from Sourceforge sources for the same version 4.1.1. There, however, its name is profile.sh and it is suggested that a symlink modules.sh pointing to that file be put in /etc/profile.d/ for on boot initialisation. Debian has moved the entire file as it seems.


The corresponding file of current version 4.2.3 at Sourceforge is a bit more elaborate and has the following content:

---

# get current shell name by querying shell variables or looking at parent
# process name
if [ -n "${BASH:-}" ]; then
   shell=${BASH##*/}
elif [ -n "${ZSH_NAME:-}" ]; then
   shell=$ZSH_NAME
else
   shell=$(/usr/bin/basename $(/usr/bin/ps -p $$ -ocomm=))
fi
...
---


instead of just the last line in the else statement. I guess it boils down to the same effect in Ubuntu or Mint as still the software is not correctly initialised.


I am CC:ing this and will forward your findings to Xavier Delaruelle who is one of the source maintainers. He wanted me to put in some tracing lines in various files of the distro package which I will presently do. Hopefully, in the not too distant future things will improve.


Cheers,

Gösta




________________________________
Från: Gunnar Hjalmarsson <gunnarhj at ubuntu.com>
Skickat: den 8 maj 2019 02:40:38
Till: Gösta Ljungdahl; ubuntu-devel-discuss at lists.ubuntu.com
Ämne: Re: compatibility issue in environment-modules version 4.1.1-1

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20190508/23a2588f/attachment.html>