Problem with "parse arg"?

The following does not seem to work correctly. The second invocation of
"argtest.rex" shown in the console log says "0 parms processed", whereas I
believe that it should say "3 parms processed". Comments? (Note: I have used
both single quote and double quote in "argtest.rex", and you might need to use
a monopitch font in order to distinguish them.)

-- from CyberSimian in the UK

-------------- console log ---------------------

E:\test\rexx>type argtest.rex
/* argtest.rex */
parse arg string
say 'parm list:'string
do i=1 by 1 while string\=''
string=strip(string)
if left(string,1)=='"'
then parse var string '"' parm '"' string
else parse var string parm string
say 'parm="'parm'"'
end i
i=i-1
say i' parms processed.'

E:\test\rexx>argtest "abc" ""
parm list:"abc" ""
parm="abc"
parm=""
2 parms processed.

E:\test\rexx>argtest "" "abc" ""
parm list:
0 parms processed.

E:\test\rexx>rexxtry
REXX-ooRexx_3.2.0(MT) 6.02 30 Oct 2007
rexxtry.rex lets you interactively try REXX statements.
Each string is executed when you hit Enter.
Enter 'call tell' for a description of the features.
Go on - try a few... Enter 'exit' to end.
parse version v
........................................... rexxtry.rex on WindowsNT
say v
REXX-ooRexx_3.2.0(MT) 6.02 30 Oct 2007
........................................... rexxtry.rex on WindowsNT
exit

Greetings,

I get different results running your test program on Linux, ooRexx 3.2 as well.

mdlueck@aleks:~$ chmod 0700 argtest.rex
mdlueck@aleks:~$ ./argtest.rex "test" ""
parm list:test
parm="test"
1 parms processed.
mdlueck@aleks:~$ ./argtest.rex "" "test"
parm list:test
parm="test"
1 parms processed.
mdlueck@aleks:~$ rexx -v
Open Object Rexx Interpreter Version 3.2.0 for LINUX
Build date: Oct 30 2007
Copyright (c) IBM Corporation 1995, 2004.
Copyright (c) RexxLA 2005-2007.
All Rights Reserved.
This program and the accompanying materials
are made available under the terms of the Common Public License v1.0
which accompanies this distribution.
http://www.oorexx.org/license.html

Syntax is "rexx [-v] filename [arguments]"
or "rexx [-e] program_string [arguments]".
mdlueck@aleks:~$

I do remember that arguments to programs at the command line are handled differently between Windows and Linux. I guess this is one such example.

--
Michael Lueck
Lueck Data Systems
http://www.lueckdatasystems.com/

In Message-ID:<_JmdnTn3wJm5ThPVRVnyvQA@bt.com>,
"CyberSimian" <CyberSimian3@BeeTeeInternet.com> wrote:

>The following does not seem to work correctly. The second invocation of
>"argtest.rex" shown in the console log says "0 parms processed", whereas I
>believe that it should say "3 parms processed". Comments? (Note: I have used
>both single quote and double quote in "argtest.rex", and you might need to use
>a monopitch font in order to distinguish them.)

I'm using Regina, but it still may shed some light.

The author of Regina made a conscious decision to make the
Windows version run like the Linux version, even though Windows
could be "better". It had to do with processing quotes on the
command line.

My understanding is that double quotes are lost before being
passed as arguments. This is unavoidable under Linux and by
choice under Regina. This explains the behavior Michael noticed
under Linux.

ooRexx obviously does see the double quotes. It might be
worthwhile seeing what happens if you try it with single quotes
and this slight modification of your code:

/* argtest.rex */
parse arg string
say 'parm list:'string
do i=1 by 1 while string\=''
string=strip(string)
quote = left(string,1)
if quote =='"' | quote == "'"
then parse var string (quote) parm (quote) string
else parse var string parm string
say 'parm=<'parm'>'
end i
i=i-1
say i' parms processed.'


--
Arthur T. - ar23hur "at" intergate "dot" com
Looking for a z/OS (IBM mainframe) systems programmer position

Michael and Arthur -- thank you for interesting posts. There are several
points here:


(1) I tried Arthur's modification to use the single quote, and of course that
works. But users invoking a command with a REXX front-end would not expect to
enclose filespecs (or other parameters) containing blanks in single quotes, so
I do not really see that as the right solution.

(2) On Windows, the command (using double quotes):

argtest "abc" ""

is processed correctly, but the command

argtest "" "abc" ""

is not. This seems inconsistent. If ooRexx can process the null string
parameter correctly in the first case, why cannot ooRexx process it correctly
in the second case? Looks like an implementation bug.

(3) I am currently thinking about porting a DOS/OS2/Windows command-line app
written in C to Linux, and have encountered the "vanishing double quotes
problem" myself. I use the Open Watcom C compiler, which has a bug in this
area. Here is an interesting test to see if ooRexx on Linux and Regina have
the same bug. Try this command (using double quotes):

argtest "a" "b c" "d"

If ooRexx on Linux, and Regina are working optimally, you should get "3 parms
processed". If you get "4 parms processed", ooRexx and Regina have the same
bug as Open Watcom.

And this is the explanation: the second parameter has SIGNIFICANT blanks. To
preserve them, the program (Open Watcom/ooRexx/Regina) needs to check the
parameter value and if it contains one or more blanks, the parameter needs to
be enclosded in double quotes when reconstituting the original parameter list
for "parse arg". So, on Linux I would expect ooRexx (if working corectly) to
generate this for the "parse arg" instruction:

a "b c" d

that is, the quotes around "a" and "d" have vanished, but the quotes around "b
c" are preserved.

Perhaps Michael/Arthur you could try this case on Linux and Regina
respectively to see what they do? Thanks.

-- from CyberSimian in the UK

In <_JmdnTn3wJm5ThPVRVnyvQA@bt.com>, on 07/29/2008
at 09:21 AM, "CyberSimian" <CyberSimian3@BeeTeeInternet.com> said:

>E:\test\rexx>argtest "" "abc" ""
>parm list:
>0 parms processed.

On OS/2 I get

[H:\]\temp\argtest "abc" ""
parm list:"abc" ""
parm="abc"
parm=""
2 parms processed.

[H:\]\temp\argtest argtest "" "abc" ""
parm list:argtest "" "abc" ""
parm="argtest"
parm=""
parm="abc"
parm=""
4 parms processed.

Have you tried slipping in a trace ?i and following the execution? How
about starting with the line

say 'argument string:' arg(1)

--
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

Arthur T. wrote:
> My understanding is that double quotes are lost before being passed
> as arguments. This is unavoidable under Linux and by choice under
> Regina. This explains the behavior Michael noticed under Linux.

How I long for a mechanism (perhaps some sort of system call) that would
give my REXX access to the command *as typed by the user* before the
system started making assumptions what the user really wanted.

I have a "select" REXX program for issuing ad-hoc database requests:

select * from table where year=2008 /* Windows OK, Linux not */
select * from table where year>1999 /* doesn't work anywhere */

A bit of history: Before Rexx started development inside IBM there were
two versions of EXEC. They both worked in an environment where all
commands were broken up into words with a maximum length of 8
characters, and translated to upper case. EXEC2 had a function call
which allowed you to get at the actual command line issued by the users.
This allowed you to handle stuff that was impossible before.

Of course, REXX handled long strings, and lower/mixed case from the
outset, but I still find myself longing for that function that told me
precisely what the user typed.

Of course, that won't really help me. My output will still get
redirected into a file named 1999 in the second example above.
Perhaps I could find a way to write to the console even when STDOUT is
redirected to a file?

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

On 30 juil, 10:09, "CyberSimian" <CyberSimi...@BeeTeeInternet.com>
wrote:
> (2) *On Windows, the command (using double quotes):
>
> * * * argtest "abc" ""
>
> is processed correctly, but the command
>
> * * *argtest "" "abc" ""
>
> is not. This seems inconsistent. *If ooRexx can process the null string
> parameter correctly in the first case, why cannot ooRexx process it correctly
> in the second case? Looks like an implementation bug.

Indeed, it's a bug... The rexx function arg() returns 0 instead of 1.
Got a look at the source files :
ooRexx for Windows calls the Win32 function GetCommandLine() which
returns
the command-line string for the current process. Ex :
c:\myexepath\rexx.exe c:\myscriptpath\argtest.rex "" "abc ""
This string is parsed by the function getArguments() to build the
arguments
string that will be passed to the rexx script.
After having called twice the function nextArgument() to skip the
executable
and the rexx script, nextArgument() is called again to test if there
are script
arguments.
When the first arg is "" then nextArgument() returns null because the
arg's length
is 0. And the argument counter remains to zero. Not good...

Under Unix, the arguments string is built by iterating over argv[] and
concatenating the values. The split made by the C runtime in argv[] is
lost
because of the concatenation :
if (arg_buffer[0] != '\0') /* not the first
one? */
strcat(arg_buffer, " "); /* add an
blank */
strcat(arg_buffer, argv[i]); /* add this to the argument
string */
Since there is no surrounding quotes around each arg, I don't see how
a rexx
script can rebuild the array from the string...

The bug under Windows can be fixed.
We should have the same behavior under Unix, but I don't know if a
function
similar to GetCommandLine() exists under Unix...

And to be complete, the feature request 1167002 "Extend Rexx command
line argument access."
should be implemented. Summary : The Parse instruction and the Arg()
builtin function should be extended to allow access to the "raw"
command arguments.

Jean-Louis

On Thu, 31 Jul 2008 08:15:06 UTC, Steve Swift
<Steve.J.Swift@gmail.com> wrote:

> Arthur T. wrote:
> > My understanding is that double quotes are lost before being passed
> > as arguments. This is unavoidable under Linux and by choice under
> > Regina. This explains the behavior Michael noticed under Linux.
>
> How I long for a mechanism (perhaps some sort of system call) that would
> give my REXX access to the command *as typed by the user* before the
> system started making assumptions what the user really wanted.
>
> I have a "select" REXX program for issuing ad-hoc database requests:
>
> select * from table where year=2008 /* Windows OK, Linux not */
> select * from table where year>1999 /* doesn't work anywhere */
>
> Of course, that won't really help me. My output will still get
> redirected into a file named 1999 in the second example above.

Have you tried quoting the SQL string? Perhaps this would prevent the
redirection.

> 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?




--

John Small

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

Addendum:

As well as checking for the presence of a blank in the parameter value, there
are other characters that should probably be checked for too:

(1) Asterisk.
If the user specifies an unquoted asterisk on the invocation of the REXX
program, the Linux shell will replace it by a list of all files and
directories in the current directory. If the user encloses the asterisk in
double quotes, the asterisk is passed to the REXX program unchanged (but with
the double quotes removed, of course). I would expect that if the user
specified ABC*, the Linux shell would replace that by a list of files and
directories with names begin ABC (I have not actually tried that, so I may be
wrong). Therefore, if the REXX program receives a parameter that contains an
asterisk, there must have been double quotes around it that should be
re-instated when "parse arg" is processed.

(2) Redirection symbols "<" and ">".
On Windows, the redirection symbols are interpreted as simple data characters
if they are in quoted strings; I would assume that the same applies on Linux
(but I have never tried that, so I may be wrong). So again, if the REXX
program receives a parameter containing either < or >, there must have been
double quotes around it originally, and they should be re-instated.

(3) Other characters.
Same processing for other special characters (although none come to mind at
the moment).

-- from CyberSiman in the UK