#981: simfactory fails on hopper when the login shell is csh ------------------------+--------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Keywords: | ------------------------+--------------------------------------------------- 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.
#981: simfactory fails on hopper when the login shell is csh -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by bmundim):
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.
#981: simfactory fails on hopper when the login shell is csh -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by rhaas):
Just kidding. It's clearly a bug. I just have no idea how to begin fixing it.
#981: simfactory fails on hopper when the login shell is csh -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by bmundim):
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.
#981: simfactory fails on hopper when the login shell is csh -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by bmundim):
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.
#981: simfactory fails on hopper when the login shell is csh -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by rhaas):
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.
#981: simfactory fails on hopper when the login shell is csh -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by eschnett):
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.
#981: simfactory fails on hopper when the login shell is csh -------------------------+-------------------------------------------------- Reporter: rhaas | Owner: eschnett Type: defect | Status: new Priority: minor | Milestone: Component: SimFactory | Version: Resolution: | Keywords: -------------------------+--------------------------------------------------
Comment (by rhaas):
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.
trac@lists.einsteintoolkit.org
-
Einstein Toolkit