errata : there are no --args option in the <command> tag examples.

<command interpreter="bash"> rcode.R $in_data $out_data </command>     ### FAILURE

<command interpreter="bash"> /full/path/to/rcode.R $in_data $out_data </command>   ### SUCCESS

On 12 November 2010 14:09, Anthony Ferrari <> wrote:
OK. I have made some tests this morning to figure this all out.

Indeed, the problem with ">" is that it catches every single message R sends to STDOUT and not only object of your interest, so this is definitely not a reliable solution. Solution suggests by Alex worked perfectly well. 

I would suggest also to use the 'trailingOnly=TRUE' option within the commandArgs() call in the R script. That allows you to only care about the args given after the '--args' option. You can then forget how many previous options you have in your command line (--vanilla, --slave, -f or others...). First parameter useful to your R script would then be commandArgs(trailingOnly=T)[1] and so on.

There is just another little point that I would like to clarify. At the beginning my tests didn't work at all and I realize that I have to give the full path to the R script (in the command tag) to make it work.

<command interpreter="bash"> rcode.R --args $in_data $out_data </command>     ### FAILURE

<command interpreter="bash"> /full/path/to/rcode.R --args $in_data $out_data </command>   ### SUCCESS

However, and rcode.R are in the same directory. 

To shed a light on this, I made an `echo $PWD` in and it returned :


where Num is the number of the job submitted to the PBS queue.

Is that a known feature ?

here follows the content of

# Function that writes a message to stderr and exits
    echo "$@" >&2
    exit 1

# Ensure R executable is found
which R > /dev/null || fail "'R' is required by this tool but was not found on path" 

# Extract first argument
rcode=$1; shift

# Ensure the file exists
test -f $rcode || fail "R input file '$rcode' does not exist"

# Invoke R 
R --vanilla --slave --file=$rcode --args $*



On 11 November 2010 09:07, Freddy <> wrote:
The is simply picked up by galaxy:
As long as you define your variable capturing the output and also in your tool.xml file.

Make sure the output is defined as "data" in the tool.xml file.

Initially I thought the same thing, but the piping is not needed with '>', worse, it doesn't work like that.