Problem receiving parameters on rexx call

  • pjbr34

    pjbr34 - 2008-07-11

    Hi, list. I have a problem I have recently noticed: I have this on my Linux directory:

    /rexx/prueba> l > pepe
    /rexx/prueba> l > pepe1.txt
    /rexx/prueba> l > pepe2.txt
    /rexx/prueba> l > pepe3.txt

    When I execute my rexx program trying to process the list of programs (that is: pepe, pepe1.txt, pepe2.txt and pepe3.txt) I issue:

    /rexx/prueba> rexx del2.rexx pepe*

    Inside the program I have:

    parse arg queborro
    say queborro

    and when I execute the program, this is the output I get:

    pepe pepe1.txt pepe2.txt pepe3.txt

    But what I would expect is:


    Why does Linux substitute * by the list of files instead of processing it as a text-chain parameter ?

    Is there a way to achieve the output "pepe*" be the result instead of the list of files ?

    Thanks in advance


    • David Ashley

      David Ashley - 2008-10-08

      I guess I am not sure what point it is you are trying to make. This behavior on Linux has been there since the beginning. Yes, it is different than the way it works on Widows. But that can not be helped or worked around by the ooRexx application. Such is life when coding for multiple operating systems. Some things are just not portable.

      • Hagrinas

        Hagrinas - 2008-10-28

        My point was in response to "We have considered fixing this situation but ..."

        I understand the reasoning for the answer of no and have no problem with it. But there are changes made that do affect programs that ran on a previous release but will not run the same when there is a new release, irrespective of OS changes.

        The other point is that if a change is considered (as above) a general stated set of guidelines could have dictated the appropriate disposition. It could have included a guideline or policy dictating that functional changes that affect established behavior are allowed when... and not allowed when...(section for each scenario, such as the following)... or when operating system differences mandate the incompatibility, the behavior is well known, and a change would potentially break existing code... and so forth.

        In the above scenario, the answer would have changed from "We have considered..." to "The guidelines disallow such a change because..."

        With guidelines for the changes that ARE allowed, they could stipulate why, that the change must be in the release notes, etc.

        That way, when I upgraded to 3.2.0, I would have known that some of my programs would break unless I made changes. I would have been able to change them in advance rather than discovering that they broke and fixing them after the fact.

        There's also the potential issue, which should be a separate thread, that ooRexx is typically installed on a machine by machine basis. So there are programs that will run on one PC but not another, even when no new language features are used, if the PCs are not running the same release.

    • Perry Werneck

      Perry Werneck - 2008-07-11


      As far I know this is related to the linux command-line processor, try running the command in this format...

      rexx del2.rexx "pepe*"

    • Nobody/Anonymous

      This is a direct result of the Linux command shell (bash). On Linux, the command line as typed by the user is not available to the executing program. Instead, the shell is responsible for parsing and expanding the command line. So any characters like '?' and '*' get expanded by the shell prior to passing the command line arguments to the target program (ooRexx in this case).

      In fact, the problem is worse than you might expect. ooRexx tries to reconstruct the command line from all of the separate arguments supplied by the shell. However, ooRexx does NOT place double quotes around an argument that contains an embedded blank in this reconstruction. Here is an example.

      You type this to the shell

      rexx myscript.rex "the quick brown fox"

      If you say arg(1) from myscript.rex the output will be

      the quick brown fox

      We have considered fixing this situation but we feel it would break a number of existing programs on Linux. I believe that it should be fixed but others are not so sure. If you strongly afree with me please open a bug report on this issue.

      David Ashley

    • Hagrinas

      Hagrinas - 2008-10-08

      There is a general issue here. When, if ever, should the language be changed in a way that existing programs might break? In my opinion, there should be a policy to go by.

      If a language is upwards compatible, features should not break. But in some cases, certain behavior is deemed to be a bug. If a programmer had used a workaround based on actual behavior, or thought it was correct behavior, things break.

      I can think of several examples going from 3.1.2 to 3.2.0. Arguably, the previous behavior should not have been expected. But there was no clear way of knowing up front how upgrading would affect them.

      I think any development task should include usage notes for whoever prepares the readme file and documentation. In the past, there wasn't enough time to address these adequately, but I'd gladly step in if help is needed to prepare these for release.

      In general, there are ways to avoid problems for the users. Sometimes a fix could still allow the previous behavior, and a documentation change could address things. Sometimes the documentation could be clarified if it was ambiguous. Implementation notes could address the rest.

      Some languages have ways of specifying feature levels or language levels or other global options that can affect behavior on a program by program basis. This concept allows introducing new syntax or features that are incompatible, but can be turned on or off. I'm not saying that ooRexx should or shouldn't do this, but all cards should be on the table when deciding a general policy for such changes.


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks