I don't see any disadvantage to using
qsub to background jobs that I typically would run interactively inside of screen. If you have a cluster available, then this is an optimal solution.
Although we have a job scheduler available, for a long time I tended to use screen to background long-running jobs or achieve parallelism without a lot of qsub script-writing overhead. Eventually, the limitations of this approach became apparent, and I wrote this qsub wrapper
qgo to allow me to replace
mkdir -p qsubscripts
qsub -w $(pwd)/qsubscripts -d $(pwd) -M firstname.lastname@example.org $@ -S /bin/zsh -
Note that I'm using my preferred shell (zsh) but of course you can remove this argument, or add others. The use of
$@ allows for the inclusion of resource specifications like
-l ncpus=4 as needed. Here's how you'd use the script:
echo 'command -a 23 -b zz' | qgo | tee jobids
STDOUT.* files will be written to
qsubscripts in the current working directory. The job ids are provided on
The working directory for the job is set as thecwd` as well, which makes it easier to write these short scripts.