<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"> <meta name="Generator" content="Microsoft Exchange Server"> <style></style> </head> <body> <style type="text/css" style="display:none;"></style> <div id="divtagdefaultwrapper" style="font-size:12pt;color:#000000;font-family:Calibri,Helvetica,sans-serif;" dir="ltr"> 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 </div> <hr style="display:inline-block;width:98%" tabindex="-1"> <div id="divRplyFwdMsg" dir="ltr">Från: Gösta Ljungdahl Skickat: den 8 maj 2019 11:26:29 Till: Gunnar Hjalmarsson; ubuntu-devel-discuss@lists.ubuntu.com Ämne: SV: compatibility issue in environment-modules version 4.1.1-1 <div> </div> </div> <div> <meta content="text/html; charset=UTF-8"> <style type="text/css" style="">  </style> <div dir="ltr"> <div id="x_divtagdefaultwrapper" dir="ltr" style="font-size:12pt; color:#000000; font-family:Calibri,Helvetica,sans-serif"> 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: --- <div># 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</div> <div>... </div> --- 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 </div> <hr tabindex="-1" style="display:inline-block; width:98%"> <div id="x_divRplyFwdMsg" dir="ltr">Från: Gunnar Hjalmarsson <gunnarhj@ubuntu.com> Skickat: den 8 maj 2019 02:40:38 Till: Gösta Ljungdahl; ubuntu-devel-discuss@lists.ubuntu.com Ämne: Re: compatibility issue in environment-modules version 4.1.1-1 <div> </div> </div> </div> <div class="PlainText">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 <a href="https://launchpad.net/~gunnarhj">https://launchpad.net/~gunnarhj</a> </div> </div> </body> </html>