Bug 1238341 - sagemath fails init environment via environment-modules
Summary: sagemath fails init environment via environment-modules
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: sagemath
Version: 21
Hardware: x86_64
OS: Linux
unspecified
unspecified
Target Milestone: ---
Assignee: Paulo Andrade
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-07-01 16:08 UTC by woky
Modified: 2015-08-23 19:49 UTC (History)
3 users (show)

Fixed In Version: 6.5-7.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-08-23 19:49:49 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description woky 2015-07-01 16:08:28 UTC
Description of problem:

It seems that sage fails to initialize its environment via environment-modules package.

  $ sage 
  /bin/sage: line 13: module: command not found
  /bin/sage: line 14: module: command not found
  /bin/sage: line 15: module: command not found
  ┌────────────────────────────────────────────────────────────────────┐
  │ Sage Version 6.3, Release Date: 2014-08-10                         │
  │ Type "notebook()" for the browser-based notebook interface.        │
  │ Type "help()" for help.                                            │
  └────────────────────────────────────────────────────────────────────┘
  sage: 

It seems this function is defined for (interactive) Zsh:

  $ whence -f module 
  module () {
	eval `/usr/bin/modulecmd zsh $*`
  }

/bin/sage runs as /bin/sh and this command/function is missing in it.

Version-Release number of selected component (if applicable): sagemath-6.3-5.fc21.x86_64

Steps to Reproduce:
1. dnf install -y sagemath
2. sage

Comment 1 Ben Liblit 2015-07-13 19:12:52 UTC
The script in "/usr/bin/sage" exhibits the aforementioned problem unless launched from an interactive bash shell.  It works when launched from bash only because of the following sequence of events:

(1) An interactive bash shell loads "/etc/profile" during initialization
(2) "/etc/profile" loads "/etc/profile.d/modules.sh".
(3) "/etc/profile.d/modules.sh" defines the "module" shell function.
(4) bash exports the "module" via the environment as $BASH_FUNC_module.
(5) "/usr/bin/sage" runs as a non-interactive bash script.
(6) Non-interactive bash does *not* load "/etc/profile" or "/etc/profile.d/*.sh"
(7) However, non-interactive bash inherits $BASH_FUNC_module from environment.
(8) Therefore, "/usr/bin/sage" has a defined "module" shell function.

Unfortunately, step (4) of the above is an unusual feature found only in bash.  I am not aware of any other shell that transmits function definitions through the environment.  Furthermore, steps (1-3) only happen for *interactive* shells.  So if "/usr/bin/sage" is run from zsh, ksh, tcsh, or any other shell, the non-interactive bash used to run "/usr/bin/sage" neither inherits "module" from its environment nor defines "module" for itself.

I recommend fixing this by adding ". /etc/profile.d/modules.sh" near the top of "/usr/bin/sage", anywhere before the calls to "module".  That way, this script will ensure that it has its own definition of the "module" function, rather than assuming it can inherit one through its environment.

For what it's worth, this bug seems to have been reported earlier as #1201757, but mistakenly (IMHO) closed as NOTABUG.  I'm not sure which of these two should be marked as a duplicate of the other, and I don't personally have permission to mark either as a duplicate anyway.  So I'll add this explanation to both, and let those with more administrative powers sort out how to manage the redundant reports.

Comment 2 Paulo Andrade 2015-07-19 18:42:43 UTC
Please let me know if you think this pseudo patch for
/usr/bin/sage is good enough:

-#!/bin/sh
+#!/bin/bash -i

In basic tests it appears to work for me.

Comment 3 Ben Liblit 2015-07-19 21:35:59 UTC
The "bash -i" fix suggested in comment #1 also works.  I suppose it looks simpler than adding ". /etc/profile.d/modules.sh" as I suggested, though actually it's doing more work: it's loading *all* interactive shell start-up code, including any provided by the user.  That feels potentially a bit brittle, but...eh, it's fine.  Either approach seems OK to me.  Thanks for giving this your attention so quickly!

Comment 4 Paulo Andrade 2015-07-25 22:26:07 UTC
While "bash -i" may be a bit overkill, it should be better
to avoid any other possible related issue with bash specific
initialization.
The major cost should be if the init files are not in the
kernel cash, that is, if they need to be loaded from disk.
For the moment I think it is safer to use "bash -i", but
I understand it may do significant more computation than
the minimum required.

Comment 5 Ben Liblit 2015-07-25 22:34:17 UTC
Paulo, that sounds perfectly reasonable to me.  Thanks!

Comment 6 woky 2015-07-25 22:39:07 UTC
Paulo, I hope that you meant is a temporary workaround because such hack shouldn't be accepted as a fix.

Comment 7 Fedora Update System 2015-08-06 14:14:51 UTC
sagemath-6.5-7.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/sagemath-6.5-7.fc22

Comment 8 Fedora Update System 2015-08-07 12:53:38 UTC
Package sagemath-6.5-7.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sagemath-6.5-7.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-12901/sagemath-6.5-7.fc22
then log in and leave karma (feedback).

Comment 9 Fedora Update System 2015-08-23 19:49:47 UTC
sagemath-6.5-7.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.