[IPython-dev] SciPy Sprint summary

[Justin Riley]

On 07/23/2010 10:07 PM, Satrajit Ghosh wrote:
> i think it still makes sense to add it in. it should be identical to the
> --queue option in that it's a switch. unfortunately, i do know of a lot
> of places where tcsh is the default shell!

So let me back up a bit. The reason you were having issues when your
shell was /bin/csh (SGE's default shell) was because of the following
line in the *generated* job script from ipcluster:

eid=$(($SGE_TASK_ID - 1))

This line doesn't work in tcsh/csh but it does in sh/bash/zsh and this
is the real underlying issue around needing to mess with the shell in
the generated job script at all.

The solution I suggested was to set /bin/sh as the default shell for all
generated job scripts submitted to PBS/SGE/LSF. It is possible to
specify the shell for a given job to use regardless of the
queueing system's default (e.g. PBS/LSF will obey the job script's
shebang #!, SGE needs #$ -S /bin/sh) and I modified the ipcluster.py
code to force /bin/sh for PBS/SGE/LSF when using the generated code.

I did this because it doesn't matter what shell the queueing system (or
user) uses by default given that we're being explicit about wanting
/bin/sh AND /bin/sh exists on every *NIX system I've encountered
(although that assumption may be wrong). Other templates used by
ipcluster.py have /bin/sh in the shebang as well so the assumption about
/bin/sh existing has been made elsewhere within the ipcluster.py code.

Having a --shell option doesn't really fix the issue because the user
will still need to know that they need to change the shell for the
generated code in the first place (because of the non-standard decrement
operation above). Ideally the user shouldn't need to think about the
shell used to execute the generated job script (their own, sure) and
really shouldn't care as long as the job script runs and launches the
engines. This combined with the fact that /bin/sh is everywhere and we
can force it is why I'm somewhat hesitant to add a --shell option for
the generated code. If the user is passing their own script, they have
full control of the shell and much more anyway so I'm only discussing
the --shell option in the context of the generated job scripts.

Does this make sense?

~Justin