-
Notifications
You must be signed in to change notification settings - Fork 203
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DEISA fork of modulecmd.tcl is missing a proper header/hashbang, which Tcl environment modules can't handle #733
Comments
@boegel can be easily fixed by defining the executable in run_cmd and passing it to the Popen call. also make this change for run_qa; and try to add a unit test for this (ie so something will break when using vsc.utils.run). |
Hi, I was sitting next to Alan when this issue emerged and, |
An example of the error in the unit tests:
|
This problem should fixed in #739 (which needs some more work to take @stdweird's suggestions into account); more work is needed to make EB play nicely with the DEISA modules though. That (old) version of Passing the shell to the See #739 for the nasty details, it is still a work-in-progress, so comments on the code are welcome there. |
fixed now #739 is merged in |
The DEISA fork of
modulecmd.tcl
, which is used on several big systems like JUROPA @ JSC, doesn't have a propertclsh
hashbang, which is causing problems when a command likemodulecmd.tcl python load GCC/4.6.3
is being run viasubprocess.Popen
, which runs it in a bash shell by default.For Tcl environment modules, any
subprocess.Popen
calls ofmodulecmd.tcl
should be using thetclsh
shell instead to dance around this problem.The text was updated successfully, but these errors were encountered: