<html> <head> <meta http-equiv="Content-Type" content="text/html; charset=Windows-1252"> <meta name="Generator" content="Microsoft Exchange Server"> <style></style> </head> <body> <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"> <p>Hi, Gunnar,</p> <p><br> </p> <p>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.</p> <p><br> </p> <p>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):</p> <p><br> </p> <p></p> <div>"Even though /usr/bin/lightdm-session is a #!/bin/bash script, it ends its execution by launching:<br> <br> /usr/bin/ssh-agent /usr/bin/im-launch cinnamon-session-cinnamon<br> <br> So ssh-agent launches /usr/bin/im-launch, which in turns launches /usr/bin/cinnamon-session-cinnamon. Both are #!/bin/sh scripts.<br> <br> 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)."</div> <div><br> </div> <div>If this conclusion is correct it means that there is no point in replacing #!/bin/sh with <span>#!/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.</span></div> <div><span></span><br> </div> <div>Apparently it is by design that dash does not export shell functions, see this:</div> <div><a href="https://www.mail-archive.com/dash@vger.kernel.org/msg01146.html" class="x_OWAAutoLink" id="LPlnk504658">https://www.mail-archive.com/dash@vger.kernel.org/msg01146.html</a></div> <div><br> </div> <div>There is also a bug report in Debian regarding this:</div> <div><a href="https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814358" class="x_OWAAutoLink" id="LPlnk472145">https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814358</a><br> </div> <div><br> </div> <div>Xavier sent me those URLs and has the following thoughts about resolution:</div> <div><br> </div> <div> <div>"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.</div> <div>...</div> <div> <div>[1] <a href="https://stackoverflow.com/a/38125775/9981498" target="_blank" rel="noopener noreferrer" id="LPlnk94575"> https://stackoverflow.com/a/38125775/9981498</a></div> <div id="LPBorder_GT_15576525081670.28635143871807356" style="margin-bottom:20px; overflow:auto; width:100%; text-indent:0px"> <table id="LPContainer_15576525081600.43798480565235487" cellspacing="0" style="width:90%; background-color:rgb(255,255,255); overflow:auto; padding-top:20px; padding-bottom:20px; margin-top:20px; border-top:1px dotted rgb(200,200,200); border-bottom:1px dotted rgb(200,200,200)"> <tbody> <tr valign="top" style="border-spacing:0px"> <td id="x_ImageCell_15576525081610.44945235846666765" colspan="1" style="width:250px; display:table-cell; padding-right:20px"> <div id="LPImageContainer_15576525081610.11004843154936517" style="background-color:rgb(255,255,255); height:250px; margin:auto; display:table; width:250px"> <a id="LPImageAnchor_15576525081630.7463842667869219" href="https://stackoverflow.com/a/38125775/9981498" target="_blank" style="display:table-cell; text-align:center"><img id="LPThumbnailImageID_15576525081630.9736200464794473" width="250" height="250" style="display:inline-block; max-width:250px; max-height:250px; height:250px; width:250px; border-width:0px; vertical-align:bottom" src="https://cdn.sstatic.net/Sites/stackoverflow/img/apple-touch-icon@2.png?v=73d79a89bded"></a></div> </td> <td id="x_TextCell_15576525081630.26789172723677546" colspan="2" style="vertical-align:top; padding:0px; display:table-cell"> <div id="LPRemovePreviewContainer_15576525081630.8862376871251022"></div> <div id="LPTitle_15576525081640.187574813941086" style="top:0px; color:rgb(0,120,215); font-weight:400; font-size:21px; font-family:"wf_segoe-ui_light","Segoe UI Light","Segoe WP Light","Segoe UI","Segoe WP",Tahoma,Arial,sans-serif; line-height:21px"> <a id="LPUrlAnchor_15576525081640.8810420770061491" href="https://stackoverflow.com/a/38125775/9981498" target="_blank" style="text-decoration:none">dash shell - Regression: Exported Bash function lost after going through another process - Stack Overflow</a></div> <div id="LPMetadata_15576525081650.35998526976828826" style="margin:10px 0px 16px; color:rgb(102,102,102); font-weight:400; font-family:"wf_segoe-ui_normal","Segoe UI","Segoe WP",Tahoma,Arial,sans-serif; font-size:14px; line-height:14px"> stackoverflow.com</div> <div id="LPDescription_15576525081660.3412364479019703" style="display:block; color:rgb(102,102,102); font-weight:400; font-family:"wf_segoe-ui_normal","Segoe UI","Segoe WP",Tahoma,Arial,sans-serif; font-size:14px; line-height:20px; max-height:100px; overflow:hidden"> 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 </div> </td> </tr> </tbody> </table> </div> "<br> </div> 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.</div> <div><br> </div> <div>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.</div> <div><br> </div> <div>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. <span>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. </span>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.</div> <div><br> </div> <div>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.</div> <div><br> </div> <div>There are two paths defined in the initialisation code:</div> <div><br> </div> <div> <div>/usr/share/modules/modulefiles</div> <div>/usr/share/modules/modulefiles/$MODULE_VERSION</div> <div><br> </div> <div>The second one becomes equivalent to the first if <span>MODULE_VERSION</span> is not defined and this causes the double report. It is basically a packaging issue, Xavier says, as the second path "<span>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.</span>" 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.<br> </div> <div><br> </div> <div>Xavier will also add code to disregard the second path if it is already defined.</div> <div><br> </div> <div>Cheers,</div> <div>Gösta<br> </div> </div> <p></p> </div> <hr tabindex="-1" style="display:inline-block; width:98%"> <div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>Från:</b> Gunnar Hjalmarsson <gunnarhj@ubuntu.com><br> <b>Skickat:</b> den 8 maj 2019 15:36:28<br> <b>Till:</b> Gösta Ljungdahl; ubuntu-devel-discuss@lists.ubuntu.com<br> <b>Ämne:</b> Re: SV: compatibility issue in environment-modules version 4.1.1-1</font> <div> </div> </div> </div> <font size="2"><span style="font-size:10pt;"> <div class="PlainText">On 2019-05-08 14:07, Gösta Ljungdahl wrote:<br> > Hi, Gunnar,<br> > <br> > Tested editing /etc/profile.d/modules.sh to source <br> > /usr/share/modules/init/bash by default i.e. commented out the line<br> > <br> > . /usr/share/modules/init/sh<br> > <br> > and put in<br> > <br> > . /usr/share/modules/init/bash<br> > <br> > but it was not sufficient. Apparently dash comes in at a later stage.<br> <br> So it seems. There are probably a couple of pitfalls built-in in that <br> program.<br> <br> Thanks for bringing the issue to the upstream maintainer! It would be <br> great if you could get back here and let us know the outcome of the <br> discussion/tests.<br> <br> -- <br> Gunnar Hjalmarsson<br> <a href="https://launchpad.net/~gunnarhj">https://launchpad.net/~gunnarhj</a><br> </div> </span></font> </body> </html>