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 <[email protected]>
Skickat: den 8 maj 2019 02:40:38
Till: Gösta Ljungdahl; [email protected]
Ä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
--
Ubuntu-devel-discuss mailing list
[email protected]
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel-discuss
