[Oorexx-bugs] [ oorexx-Bugs-2825120 ] Rexx bad -arguments not rejected

[SourceForge.net <no...@so...>]

Bugs item #2825120, was opened at 2009-07-21 19:47
Message generated for change (Comment added) made by bigrixx
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2825120&group_id=119701

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Interpreter
Group: v4.0beta
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Mark Gaubatz (mgaubatz)
Assigned to: Nobody/Anonymous (nobody)
Summary: Rexx bad -arguments not rejected

Initial Comment:
4.0 RC 2

Issuing:

  rexx -b foo

-b not rejected as invalid. Expected:

Syntax is "rexx [-v] filename [arguments]"
or        "rexx [-e] program_string [arguments]".


----------------------------------------------------------------------

>Comment By: Rick McGuire (bigrixx)
Date: 2009-07-22 14:30

Message:
I contribute my two cents worth.  This does need to be fixed...eventually. 
However, this bug has been in this executable at least since the open
source contribution was made from IBM, so I don't see there being much of a
rush to fix it.  

The entire area of argument parsing for these command line utilities needs
to be cleaned up, and it would be nice if the different executables did not
duplicate common code pieces such as error message processing.  This is
certainly something that can be deferred to a future release, so leaving
this bug open is the appropriate thing to do. 

----------------------------------------------------------------------

Comment By: Mark Miesfeld (miesfeld)
Date: 2009-07-22 14:22

Message:
aresti,

Well, I have never claimed to be a Rexx expert, I just bumble along the
best I can.  <grin>

"A typo could lead to subtly different behavior with no indication that
anything was amiss."

This seems to me to validate what I was saying.  In a program with a
complex command line; a lot of different switches and arguments to the
switches, then a typo could lead to subtly different behavior.  And I said,
in those cases I thought it was important to flag bad switches.

But, in this case, the invocation of rexx, it seems to me there is 0
chance of a typo leading to any difference in program behavior.

Suppose you meant to type rexx -v to see the version and had any typo:

C:\work.ooRexx\wc\main>rexx -b

Syntax: REXX [-v] ProgramName [parameter_1....parameter_n]
or    : REXX [-e] ProgramString [parameter_1....parameter_n]

C:\work.ooRexx\wc\main>rexx -d

Syntax: REXX [-v] ProgramName [parameter_1....parameter_n]
or    : REXX [-e] ProgramString [parameter_1....parameter_n]

You get the syntax, which is exactly what you would get if the -b or -d
was flagged as an error.

Say you meant to type rexx -e <program_string>

C:\work.ooRexx\wc\main>rexx -f "say hello"
Error 3:  Failure during initialization
Error 3.901:  Failure during initialization: Program "say hello" was not
found

It gets flagged as an error immediately and it should be / is easy to spot
the error.

Say you meant to invoke a program and you accidently added in an invalid
switch:

C:\work.ooRexx\wc\main>rexx -g qtest.rex
file exists: C:\work.ooRexx\wc\add.rex
f: C:\work.ooRexx\wc\add.rex

C:\work.ooRexx\wc\main>rexx -q qtest.rex
file exists: C:\work.ooRexx\wc\add.rex
f: C:\work.ooRexx\wc\add.rex

C:\work.ooRexx\wc\main>

Your program executes as you expected it to.

So, in this case

1.) It changes existing behavior.  Prior to 4.0.0, invalid switches were
always ignored.

2.) I can't think of a single case where flagging the invalid switch is
more useful than the existing behavior.

That's why I wasn't inclined to change the existing.  <grin>  But, it is
easy enough to do, a minute or two of coding, which I had already done:

C:\work.ooRexx\wc\main>rexx -b qtest.rex

Syntax: REXX [-v] ProgramName [parameter_1....parameter_n]
or    : REXX [-e] ProgramString [parameter_1....parameter_n]

C:\work.ooRexx\wc\main>

We'll see if anyone else pipes in.

----------------------------------------------------------------------

Comment By: aviatrexx (aresti)
Date: 2009-07-22 05:45

Message:
I don't know about you experts, but if ooRexx just ignored an invocation
option that it didn't recognize, it would raise _my_ Astonishment Factor. 
A typo could lead to subtly different behavior with no indication that
anything was amiss.  It is not sufficient that all valid flags are
recognized, invalid flags must be noted (at the least) to give the poor
programmer a fighting chance.  Anything less fails to rise to the canonical
Rexx behavior for meeting user expectations.

However, nothing is perfect; I once worked on a suite of Classic Rexx
programs whose author started each EXEC with "Trace ON".  He never did
figure out why he never got any tracing lines...

----------------------------------------------------------------------

Comment By: Mark Miesfeld (miesfeld)
Date: 2009-07-21 21:57

Message:
Hi Mark,

This is actually working as designed:

    default:                /* ignore other switches             */
      break;

It makes things simplier in the start up code.  Maybe simplier for the
user, I suppose that's debatable.

In command line programs that have a lot of switches, and arguments to
switches, I think it is important to flag bad command lines because it is
likely the user *thought* he had the right command line.  In this case, I
doubt people are using the -b option expecting some specific behaviour,
that then doesn't happen.

I'm not inclined to change this, but I'll leave it open and see if other
people think it is a bug.

By, the way, I appreciate your attention to detail in testing 4.0 before
the release.  So, don't be discouraged if we don't see some of these things
as bugs.  <grin>

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=684730&aid=2825120&group_id=119701