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

Sun May 12 11:02:08 UTC 2019

Hi, Gunnar,

Xavier Delaruelle finished his investigation a couple of days ago but my plate was full with other things so I couldn't report back to you right away.

In short: Xavier reproduced my issue in both Mint 19 and Ubuntu 18.04 virtual machines. His analysis show that the environment module code stays on track and there is nothing that he can do to amend the code regarding initialisation via the sourcing of /etc/profile.d/-scripts. The derailment occurs after the initialisation of the program at the end of, in my case, lightdm-session which finishes like so (I quote Xavier):

"Even though /usr/bin/lightdm-session is a #!/bin/bash script, it ends its execution by launching:

  /usr/bin/ssh-agent /usr/bin/im-launch cinnamon-session-cinnamon

So ssh-agent launches /usr/bin/im-launch, which in turns launches /usr/bin/cinnamon-session-cinnamon. Both are #!/bin/sh scripts.

So at that point, from what I understand, if /bin/sh points to /bin/dash, the defined shell functions are lost (including the 'module' shell function)."

If this conclusion is correct it means that there is no point in replacing #!/bin/sh with #!/bin/bash in any scripts defining and exporting shell functions that are sourced by lightdm-session unless it is also done for any such script that runs later. This, I take it, would be more or less equivalent to let /bin/sh point to /bin/bash.

Apparently it is by design that dash does not export shell functions, see this:
https://www.mail-archive.com/dash@vger.kernel.org/msg01146.html

There is also a bug report in Debian regarding this:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814358

Xavier sent me those URLs and has the following thoughts about resolution:

"Having a proper fix to this equals, from my understanding, to fix [1] or to make /etc/bash.bashrc script sources the /etc/profile.d/*.sh scripts. Both have a lot of potential side-effect so I believe that the developpers of these Linux distributions will not release such solution quickly.
...
[1] https://stackoverflow.com/a/38125775/9981498
[https://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-icon@2.png?v=73d79a89bded]<https://stackoverflow.com/a/38125775/9981498>

dash shell - Regression: Exported Bash function lost after going through another process - Stack Overflow<https://stackoverflow.com/a/38125775/9981498>
stackoverflow.com
When moving from Ubuntu 14.04 to 16.04, I've noticed several of my Bash scripts failing due to missing exported functions. I wonder whether this is related to the fixes for the Shellshock bug, even

"
As it is more than three years since this issue regarding dash surfaced I don't think it is very likely that the dash developers will reintroduce a functionality that was removed in the first place motivated by POSIX conformity. This leaves postponing the sourcing of /etc/profile.d/-scripts until every conceivable #!/bin/sh-script has finished for instance by sourcing in ~/.bashrc and whatever changes that would necessitate. But then sourcing by way of ~/.bashrc goes against the idea of separating initialisation code that needs to be run once per login from code that needs to be run every terminal session.

So this issue is a manifestation of a conflict between desirable goals and like Xavier I don't expect a solution any time soon even if I file a bug report.

So while waiting for a solution that may never come I believe that the best thing would be not to source any code that defines shell functions during graphical login.  Having to reinitialise in ~/.bashrc or on the command line then results in a less clean initialisation.  To filter software in this respect would require more work by the people who package software and that's a disadvantage so not likely to happen. For me, though, I think I prefer redirecting /bin/sh to /bin/bash and live with the performance degradation regarding speed and deal with potential but not very likely other issues if and when they come. Perhaps we will see no change at all in the foreseeable future.

The other problem that I had with double report of system modules, see my Mint forum post, Xavier also reproduced but here he can do something.

There are two paths defined in the initialisation code:

/usr/share/modules/modulefiles
/usr/share/modules/modulefiles/$MODULE_VERSION

The second one becomes equivalent to the first if MODULE_VERSION is not defined and this causes the double report. It is basically a packaging issue, Xavier says, as the second path "is enabled but the environment variable used for that (MODULE_VERSION) is not defined nor correspond to some existing modulefiles directory in the package. A bug report against the root distribution (Debian I think) should be a good thing." It kind of sounds like Xavier wants me to make that bug report. Then again, I don't know if there is any significant difference between Debian and  Ubuntu regarding this package but perhaps you can tell me.

Xavier will also add code to disregard the second path if it is already defined.

Cheers,
Gösta

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

On 2019-05-08 14:07, Gösta Ljungdahl wrote:
> 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.

So it seems. There are probably a couple of pitfalls built-in in that
program.

Thanks for bringing the issue to the upstream maintainer! It would be
great if you could get back here and let us know the outcome of the
discussion/tests.

--
Gunnar Hjalmarsson
https://launchpad.net/~gunnarhj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-devel-discuss/attachments/20190512/c33a3025/attachment.html>