Hi guys,
I filed a bug in GRAM5: http://jira.globus.org/browse/GRAM-339
Is it a known behaviour?
------------------------------------------------------------------
Using the GRAM5 service to run jobs, we have found a bug in the
globus-job-run / globus-job-submit utilities. These commands do not
process certain arguments passed to them correctly.
For instance, consider the following example:
globus-job-run -dumprsl foo.example.com/bar /usr/bin/perl -e "exit(33)"
This produces the following output:
&(executable="/usr/bin/perl")
(arguments= "" "exit(33)")
Note that the first argument in the RSL code produced is empty, where it
should actually be "-e". This does not happen when using other typical
command line switches, e.g. "-p" or "-i".
Please also note that this is not a matter of quoting strings properly
in the shell when calling globus-job-run, nor is it limited to calling
perl. Any of the following strings "-e" "-n" "-E" (or a combination
thereof) is eaten up by the globus-job-run command and is not properly
transformed into RSL.
Looking into the cause for this, we found out that the problem is with
the "echo" command used inside the globus-job-run script. As far as we
could tell, there is no way to stop echo from considering "-e", "-n", or
"-E" to be a switch to the echo command itself instead of just a string
to output. Therefore, little can be done to rectify this problem when
using "echo" (bash's manpage explicitly states that echo does not honor
"--" to mean the end of arguments like other shell utilities do).
As a workaround, we changed the globus-job-run script to use "printf"
instead of "echo" when processing arguments to be passed to the
executable eventually to be processed remotely. See the attached patch
file for the solution we came up with. While it solves the problem at
hand, it might be worthwhile to expand this to replace other instances
of "echo" with "printf" as well. On the other hand, switches like "-e"
are hardly ever relevant in other contexts of the globus-job-run script,
so the patch could be considered "good enough" as well.
What we would like to see is a fix like the above incorporated into a
future release of Globus. This would enable us to update our
installation to newer versions of Globus without having to worry about
this problem again.
Thanks,
Sebastian
--
Sebastian Czechowski [email protected]
IT Project Coordinator
GridwiseTech office: +48 12 294 71 20
The Scalability Specialist www.gridwisetech.com
