[Toolserver-l] Solving problems with qsub with -b y option

[Marcin Cieslak]

>> Marcin Cieslak <saper at saper.info> wrote:
>>> Magnus Manske <magnusmanske at googlemail.com> wrote:
>> On Mon, Feb 28, 2011 at 2:28 PM, Marcin Cieslak <saper at saper.info> wrote:
>>>>> Magnus Manske <magnusmanske at 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