[torqueusers] command line parameters

Garrick Staples garrick at clusterresources.com
Thu Oct 19 21:52:21 MDT 2006


On Fri, Oct 20, 2006 at 01:34:40AM +0100, Craig Macdonald alleged:
> 
> > A potential problem with this is that there are three different shell
> > startup options in TORQUE (--enable-shell-pipe [default], --disable-
> > shell-pipe, and --enable-shell-use-argv), and I'm not sure that this
> > feature could be made to work with all three of them without some
> > seriously ugly hacks.
> 
> I havent had a chance to study the relevant code in detail. 
> so please pardon my naievity, but I presume that the jobs scripts are 
> started in the following manners:

Noone bothers to look at that code more than once a year, so we are all
pretty naive about it.

 
> #--enable-shell-pipe
> cat job.SC | sh
> #--enable-shell-use-argv
> sh job.SC
> 
> How does the third option function (--disable-shell-pipe)?
> Is this a direct execution of job, as if it executable?

(where "shell" is the user's login shell)

--enable-shell-pipe [default]:
  echo 'job.SC' | -shell </dev/null

--disable-shell-pipe:
  -shell < job.SC

--enable-shell-use-argv (overrides shell-pipe option):
  -shell job.SC </dev/null

 
> Moreover, what are the respective advantages and disadvantages
> of each option? Are all necessary, or is it for platform-specific quirks?

It is an evolution.  The original shell pipe is from the original
OpenPBS code.  Then someone decided they wanted the shell to read the
script on stdin (distinct disadvantage that anything inside of the
script that reads on stdin will break the script) created the shell-pipe
option.

Then someone else decided that passing the script as an arg to the shell
was the cool way to do things and created the shell-use-argv option.


The 1st option clearly wins the popularity contest because few people
bother to change the option, and is the only option that can possibly
work with binaries.

The 2nd option allows you to do goofy things like using arbitrary
interpreters.  Imagine specifying perl as the job's shell and feed it
pure perl, just be sure to never read from stdin.

The 3rd option is... well, I bet Troy has a good answer for this.

 
> The support for job args could be conditionally defined in the code
> if --enable-shell-use-argv is enabled?

It is obviously possible for the 1st and 3rd options, but clearly
impossible or the 2nd.

 
> >Another problem is that globs won't necessarily work the way people
> >expect.
> 
> Shell expansion globbing is normally done by the shell, when a command is execute.
> As I see it, either the job could cd to $PBS_O_WORKDIR on startup, or filenames
> could be expanded to full paths (not perfect when compute nodes have
> different filesystem layouts). 

Globbing is done by the shell you are typing into, before the command is
invoked.  In only the 1st option, is the batch script (and the
hypothetical args) interpreted by a shell.

 
> Or the caveats are just left to apply. 
> I would assume that most use of arguments would be parameters to start
> jobs rather than filenames.

You haven't seen the Rube Goldberg scripts my users have come up with :)



More information about the torqueusers mailing list