On the other hand, I did check the ooRexx 3.1.0 documentation, and it doesn't mention checking the execution directory at all, so this is a change.
Bruce On Oct 29, 2011, at 3:46 PM, Chip Davis wrote: > I don't understand this. Has the submitter misunderstood that the > search order for subroutines/functions is not necessarily the same as > that for commands? > > The former is documented in Sect.7.2.1.1 and seems to be nearly > identical to the way it's described in my OS/2 REXX Reference (with > the substitution of "directory of invoking program" for "function > package". > > The latter has always been under control of the addressed environment. > There's never been any way that the Rexx processor could (or should, > imo) control that. > > What I don't understand (partially because I can't see his test code) > is how he got different results "prior to 4.1.0". > > What am I missing? > > -Chip- > > On 10/27/11 17:23 SourceForge.net said: >> Bugs item #3429383, was opened at 2011-10-27 13:23 >> >> Initial Comment: >> In Version 4.1.0, it appears that the search order as defined in the Rexx >> Reference Manual Section 7.2.1.1 "Locating External Files",page 376, was >> partially implemented. In previous versions of rexx, all the way down to >> PC-DOS Rexx, the search order began in the current directory. Now "CALL" >> works as defined in list item 1. The search for a direct invocation of the >> external .rex program still begins in the current directory. If there are 2 >> .rex programs with the same name in 2 different directories a CALL to the >> .rex program invokes the rexx program that was in the directory that the >> calling program called it. Even if I change directories, I still get the >> version of the program from the original directory. On the other hand if I >> do a direct invocation of the program I get the version of the program for >> the current directory. There are side effects of this. Doing a "CALL" >> invokes the program as a SUBROUTINE and a direct invocation causes the >> program to be treated as a "COMM > AND". I have several programs that function differently based on how they > were invoked. >> >> I've included a sample to show the difference. Here is the console output: >> [C:\]\a\test >> Hello!!! >> Hello!!! <- This used to be "Hi!!!" prior to 4.1.0 >> Hello!!! >> Hi!!! >> >> [C:\] >> >> If I had my druthers I would prefer to have the search the way it was prior >> to 4.1.0. That way, all I have to do is change directories to the version I >> want. This was a great development tool. I didn't have to modify the >> original code to begin development on a new level of the program. >> >> Also, in Section 7.2.1.1 there appears to be a couple of document problems >> that I picked up on: >> >> The second and third list items are the same. >> >> The paragraph below the first group of list items, beginning with the "The >> second element...", second sentence, has 2 "contains" in a row. >> >> Operating environment is Windows XP Professional, SP1 32bit w/ ooRexx 4.1.0 >> >> ---------------------------------------------------------------------- > > > ------------------------------------------------------------------------------ > Get your Android app more play: Bring it to the BlackBerry PlayBook > in minutes. BlackBerry App World™ now supports Android™ Apps > for the BlackBerry® PlayBook™. Discover just how easy and simple > it is! http://p.sf.net/sfu/android-dev2dev > _______________________________________________ > Oorexx-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/oorexx-devel ------------------------------------------------------------------------------ Get your Android app more play: Bring it to the BlackBerry PlayBook in minutes. BlackBerry App World™ now supports Android™ Apps for the BlackBerry® PlayBook™. Discover just how easy and simple it is! http://p.sf.net/sfu/android-dev2dev _______________________________________________ Oorexx-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/oorexx-devel
