Marcin Cieslak saper@saper.info wrote:
Magnus Manske magnusmanske@googlemail.com wrote:
On Mon, Feb 28, 2011 at 2:28 PM, Marcin Cieslak saper@saper.info wrote:
Magnus Manske magnusmanske@googlemail.com wrote:
cronsub update_dupes /home/magnus/update_dupes.pl
qsub: Unknown option
qsub: Unknown option
qsub: Unknown option
This is because you have in your script
#$cmd = "./cron_sql.sh" unless -e $cmd ;
and this is recognized by qsub(1) as the embedded qsub option.
If you change it to:
# $cmd =
it works again.
Thanks!
Wow, what a mess. Why does cronsub/qsub try to divine hidden vodoo meaning from my scripts (which predate qsub availability) anyway? If that is desired for some cases, why is that activated by default? Is there at least a qsub option to turn it off? Will that option work with cronsub?
To quote man qsub(1):
There is another option that's quite useful:
qsub -b y path-to-program
This causes path-to-program (use full path like /usr/bin/something or path relative to your $HOME or it won't work) to be executed as a "binary" program. Your script will not be copied to a temporary directory on the SGE cluster and will be ran in place.
Using "-b y" for Python scripts fixes the python import issue mentioned earlier on this list http://thread.gmane.org/gmane.org.wikimedia.toolserver/3069 (item two)
Of course then job submission does not attempt to interpret your script in any way (including hidden voodoo to read qsub parameters from it), so "#$" won't work.
Shell scripts work fine using "-b y".
//Marcin