Problem with "parse arg"?

CyberSimian wrote:
> Jean-Louis F. wrote:
>> Under Unix, the arguments string is built by iterating over argv[] and
>> concatenating the values.
>
> In the interests of fixing these problems, I hope that the reguler REXX
> followers will permit a bit of C...
>
> If REXX.EXE gets invoked with the normal parameters for a C main program, you
> will have this as the declaration:
>
> int main(int argc, char* argv[]) {etc...}
>
> argc specifies the number of parameters passed to the C program;
> argv is an array of pointers to parameter values.
>
> argv[0] is the filespec of the program invoked (i.e the REXX interpreter from
> the point of view of the OS).
>
> argv[1] is the name of the user-written REXX program to be interpreted.
>
> So the parameters to the user's REXX program begin with argv[2].
>
> If the Linux shell is working as I expect, this is the C code that you need in
> order to preserve significant blanks and significant double quotes:
>
> #define BLANK_CHR ' ' /* single blank char */
> #define QUOTE_STR "\"" /* double quote as null-term string */
> arg_buffer[0]=0;
> for (i=2; i<=argc; i++)
> {
> if ( argv[i][0]==0 /* null string? */
> || strchr(argv[i],BLANK_CHR)!=NULL ) /* or blank present? */
> {
> strcat(arg_buffer,QUOTE_STR); /* open quote */
> strcat(arg_buffer,argv[i]); /* parameter value */
> strcat(arg_buffer,QUOTE_STR); /* close quote */
> if (i<argc) /* not the last parameter?
> strcat(arg_buffer,BLANK_STR); /* add separating blank */
> }
> }
>
> -- from CyberSimian in the UK
>
>
There's one additional condition to worry about, and that's an argument
that might have included an escaped quote (and a blank) originally.
Just slapping a pair of quotes around the argument would not be entirely
correct.

Rick

Addendum 2:

On reviewing the suggested C code, I see that I did not get it quite right, as
it does not handle "normal" parameters (i.e. ones that are not null and which
do not contain a blank). Correcting the code is left as an exercise for the
reader...

-- from CyberSimian in the UK

Shmuel (Seymour J.) Metz wrote:
> [H:\]\temp\argtest argtest "" "abc" ""
> parm list:argtest "" "abc" ""
> parm="argtest"
> parm=""
> parm="abc"
> parm=""
> 4 parms processed.

You slipped in an extra "argtest" here, which is why it says "4 parms
processed". However, your post prompted me to boot up my OS/2 Warp 4.0
system and try this on Classic REXX ("parse version" gives "REXXSAA 4.00 24
Aug 1996"). On OS/2 Classic REXX the "argtest" program gives the expected
result (3 parms processed) for the case that ooRexx gets wrong, i.e.:

argtest "" "abc" ""

-- from CyberSimian in the UK

In <Hc6dnWKrdpfanw_VRVnyhgA@bt.com>, on 07/31/2008
at 07:19 PM, "CyberSimian" <CyberSimian3@BeeTeeInternet.com> said:

>On OS/2 Classic REXX the "argtest" program gives the expected result (3
>parms processed) for the case that ooRexx gets wrong, i.e.:

>argtest "" "abc" ""

My test, which gave a correct value, was usiong OREXX. What do you get if
you add a

say arg: arg(1)

to argtest.cmd?

--
Shmuel (Seymour J.) Metz, SysProg and JOAT <http://patriot.net/~shmuel>

Unsolicited bulk E-mail subject to legal action. I reserve the
right to publicly post or ridicule any abusive E-mail. Reply to
domain Patriot dot net user shmuel+news to contact me. Do not
reply to spamtrap@library.lspace.org

Rick McGuire wrote
> There's one additional condition to worry about, and that's an argument that
> might have included an escaped quote (and a blank) originally. Just slapping
> a pair of quotes around the argument would not be entirely correct.

Good point. But how does one escape a double quote on the operating-system's
or shell's command line?

Within REXX, one uses the doubling-up method to specify a double quote within
a string delimited by double quotes (not sure who did that first -- PL/I?).
On Windows, ooRexx gets the command line exactly as typed by the user, and
apparently Windows does no escape processing:

E:\test\rexx>type escape.rex
/* escape.rex */
parse arg parms
say 'parms=>>>'parms'<<<'

E:\test\rexx>escape "abc"
parms=>>>"abc"<<<

E:\test\rexx>escape "a"c"
parms=>>>"a"c"<<<

E:\test\rexx>escape "a""c"
parms=>>>"a""c"<<<

E:\test\rexx>escape "a\"c"
parms=>>>"a\"c"<<<

I don't have ooRexx installed on my Open Suse 10.3 system (I'm a Linux tyro!),
but given it's "techie" origins, I would surmise that the Linux shells use the
C backslash method to escape a double quote; i.e. if you ran "escape.rex" in
Linux you would get this:

escape "a\"c"
parms=>>>a"c<<<

If it really does behave that way, the parameter received by the user's REXX
program is different to the one received on Windows. And what do the Linux
shells do with two consecutive double quotes within a parameter delimited by
double quotes? Does that become two separate parameters?

escape "a""c"
parms=>>>a c<<<

In the former case ooRexx could recognise that an escape sequence had been
specified, and fix-up the parameter list appropriately, but it could not do
that in the latter case. So a solution that is watertight on all operating
systems may not be possible in the absence of an OS or shell call that returns
an exact copy of the original parameter list.

Be that as it may, I think that ooRexx could handle some of these cases
correctly (e.g. parameter containing a blank), even if it cannot handle all of
them correctly.

-- from CyberSimian in the UK

John Small wrote:
> Have you tried quoting the SQL string? Perhaps this would prevent the
> redirection.

My brain knows how to do that, but the message rarely reaches my
fingers. :-)
In other cases where I'm highly likely to enter redirection or wildcard
characters, I resort to ignoring the command line and prompting for the
command to run. I'd like to avoid that here.

>> Perhaps I could find a way to write to the console even when STDOUT is
>> redirected to a file?
> Have you tried writing to STDERR?

Yes, that would bypass the immediate problem. I'm a bit reluctant to do
this though, as I've had bad experiences with other programs which
reversed the normal usage of STDOUT/STDERR. It would certainly help me
out when I accidentally entered a ">" in my command. Of course, if the
">" got interpreted as redirection then my SQL would fail because the
syntax "where colname >" is invalid.

I think it's time to bite the bullet and teach my fingers to handle
correctly those characters liable to cause problems.

--
Steve Swift
http://www.swiftys.org.uk/swifty.html
http://www.ringers.org.uk