Description of problem: The "/usr/bin/Singular" script uses a "module" command to modify its execution environment. However, the "module" command is not defined within this script unless the script itself is run from within an interactive bash shell. Users with other shells will instead see an error message, and the required module will not be loaded. Version-Release number of selected component (if applicable): Singular-3.1.6-10.fc22.x86_64 How reproducible: Completely deterministic: 100% reproducible. Steps to Reproduce: 1. Change your login shell to something other than bash. 2. Log out and back in again. 3. Run command: "Singular" Actual results: /usr/bin/Singular: line 3: module: command not found Expected results: No such error message should appear. Additional info: The script in "/usr/bin/Singular" works when launched from an interactive bash shell 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/Singular" 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/Singular" 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/Singular" is run from zsh, ksh, tcsh, or any other shell, the non-interactive bash used to run "/usr/bin/Singular" 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/Singular", before the call 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. See also bug #1201757 and bug #1238341 for another instance of the same problem in a different package.
Can you try changing the /usr/bin/sage script, like this: -#!/bin/sh +#!/bin/bash -i In basic tests it appears to work for me.
Ops, replied to wrong bug :) In this case would be patching /usr/bin/Singular
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!
Singular-3.1.6-15.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/Singular-3.1.6-15.fc22
Package Singular-3.1.6-15.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 Singular-3.1.6-15.fc22' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2015-12293/Singular-3.1.6-15.fc22 then log in and leave karma (feedback).
Singular-3.1.6-15.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.