On Mon, Feb 28, 2011 at 3:24 PM, Marcin Cieslak saper@saper.info wrote:
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
Thanks, very helpful. Do you know if cronsub supports this?
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.
I believe that is default behaviour anyway now? I vaguely remember a mail concerning that WRT Python.
Cheers, Magnus