- removed comment
simfactory fails on hopper when the login shell is csh
Issue #981
wontfix
if the login shell is csh on hopper, the I get:
work/ET_trunk> simfactory/bin/sim build --thornlist=thornlists/einsteintoolkit.th
Using configuration: sim
/bin/bash: module: command not found
/bin/bash: module: command not found
/bin/bash: module: command not found
/bin/bash: module: command not found
/bin/bash: module: command not found
Reconfiguring sim
Writing configuration to: /global/project/projectdirs/m152/rhaas/hopper/ET_trunk/configs/sim/OptionList
/bin/bash: module: command not found
I am not sure if I should classify this as a bug or a feature since it makes it prevents people from using csh :-P
I am not sure out of which hat simfactory pulls the "/bin/bash" string, since "bash" does not appear in any hopper related file it seems.
Keyword:
Comments (8)
-
-
reporter
- removed comment
Just kidding. It's clearly a bug. I just have no idea how to begin fixing it.
-
- removed comment
I remember having a similar problem on trestles. The sysadmin had to fix this. If I recall correctly the /etc/profile.d/modules.csh wasn't being sourced. Do you know if this file is actually there on hopper?
Cheers, B.
-
- removed comment
Ok,
now I remember how it was fixed. Just add the following line to your submit script (assuming a bash script file and that you are working interactively in a tcsh):
. /etc/profile.d/modules.sh
before any use of module commands there (eg module purge or module load)
Cheers, B.
-
reporter
- removed comment
Yes, this file exists. The module command also worked from the command line. The problem looks more like simfactory is somehow hard coding the shell to be used when setting up the environment as /bin/bash. And indeed grep '/bin/bash' -r simfactory finds a number of matches eg.
simfactory/lib/simlib.py: command = "/bin/bash -c %s" % (QuoteSafe(command)) simfactory/lib/simlib.py: logonly("executed: /bin/bash -c %s" % " ".join(args)) simfactory/lib/simlib.py: os.execv('/bin/bash', args) which do seems like likely culprits. I just tried replacing these by os.environ["SHELL"] which fails since simfactory actually uses bash features.
I just read your second post Bruno. I guess that will work if I added it to envsetup. Though then it will fail if users are actually using bash and have already loaded modules. I somewhat dislike putting a module purge in envsetup since it means that simfactory will completely ignore any currently loaded (eg. extra) modules. Thank you for pointing this out though. It is definitely a possible solution.
-
- removed comment
Simfactory uses bash syntax in all its scripts and in all the commands it executes. The reason is that it is impossible to write "generic" shell code if one wants to use any non-trivial features, and therefore one has to make a choice.
Simfactory should be unaffected by any of your shell startup settings. This should neither be necessary, nor should it confuse simfactory.
It may well be that the command ". /etc/profile.d/modules.sh" is missing in the run script.
-
reporter
- removed comment
This does not happen when I try to run something (I did not get that far yet) but already when I try to build the configuration. It seems as if it is required in envsetup already for the build process.
-
reporter
- edited description
- changed status to wontfix
Hopper has been dead for more than 2 years.
Issues like this are typically due to module systems not being initialized and most simfactory entries on machines where this is an issue explicitly source files to initialize the module system.
- Log in to comment
I am not sure if I should classify this as a bug or a feature since it makes it prevents people from using csh :-P
Well, tcsh is a very good interactive shell. For example, its built-in alias mechanism is great and IMHO much better than the bash one.
Cheers, B.