Rick has just been VERY busy, and not had a chance to investigate this. On Fri, Jun 26, 2009 at 11:32 AM, Mark Miesfeld<miesf...@gmail.com> wrote: > On Thu, Jun 25, 2009 at 6:17 PM, James Johnson<j...@iland.net> wrote: >> >> 1) Open a terminal session. Your are in some directory that we will call >> "home". >> 2) Within the "home" directory is a sub directory "dirA". >> 3) Within "dirA' is a sub directory "dirB". >> 4) Within "dirA" is a rexx program named "progA". >> 5) "progA" calls "progB" which resides in "dirB". > > Okay, after sleeping on it, I'll revise what I said. > > When progA calls progB, it searches a *path* for the file progB. The > first entry in that path is the *directory* dirA. progB is not in > dirA. Nor is progB in any other directory in the path. So it > shouldn't be found on either Windows or Linux. > > So the bug is that it is found on Windows. The bug is not that it > should be found on Linux.
I really don't agree with this assertion that this is a Windows bug. The "name" you specify is used to search along the path constructed from the elements I cited. The relative directory just adds to the resolution and I would expect this to behave the same on both Linux and Windows.... with a couple of caveats. 1) The path delimiter is different between the two platforms. 2) The Linux file system is case sensitive. Since the name is in calculated string form, there is no case folding involved in evaluating the name, so there might be mismatches. The Linux system will try the name both asis and in all lowercase to get better resolution. Given the above constraints, if this is not found, then this would appear to be a Linux bug. I probably won't have time to take a closer look until this evening. > > And in fact if you run your example under 3.2.0 on Windows, progB is not > found: > > E:\ooTest\home>rexx -v > Open Object Rexx Interpreter Version 3.2.0 > Build date: Oct 30 2007 > Copyright (c) IBM Corporation 1995, 2004. > Copyright (c) RexxLA 2005-2007. > > E:\ooTest\home>rexx dirA\progA > In progA. Current working directory: E:\ooTest\home > 6 *-* call (prog) > Error 43 running E:\ooTest\home\dirA\progA line 6: Routine not found > Error 43.1: Could not find routine "dirB\progB" > > E:\ooTest\home> > > Now personally, I sort of feel that: > > * the first attempt to find progB should be to treat the target of the > call (dirB/progB) as a relative file name to the directory that the > executing program resides in. > > * the second attempt to find progB should be to treat the target of > the call (dirB/progB) as a relative file name to the current working > directory. > > * then search the paths: > > 3) The extension path > 4) The REXX_PATH > 5) The system path. I don't see these as being different. For any sort of path search, the name you are searching for is relative to the directories in the search path. That is, you have a target file, you concatenate it with the directory you're looking in and see if you get a hit. > > However, as your example shows, the behavior you want was not present > in Windows ooRexx 3.2.0, so that would be a change in behavior. > > And, since Rick hasn't responded to this, I sense that he is opposed > to a change here. > > You could open up a Request For Enhancement for the behavior you want. > Maybe it would be accepted and implemented in a future version. 4.0 added new bits to the file lookup: 1) The relative to the calling file location 2) The extension path 3) The REXX_PATH variable. 1) is the culprit for this lookup behavior, and is the expected result. Linux possibly has a bug here, but I've not had an opportunity to investigate yet. It was certainly intended to work that way. If either of these got it wrong, I'd have expected the problem to come from Windows rather than Linux, since we let the Windows search APIs do the heavy lifting for us, while on Linux, we have to implement the path search ourselves. I'd have placed a higher probability on unexpected behavior on the Windows API. Rick > > -- > Mark Miesfeld > > ------------------------------------------------------------------------------ > _______________________________________________ > Oorexx-devel mailing list > Oorexx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/oorexx-devel > ------------------------------------------------------------------------------ _______________________________________________ Oorexx-devel mailing list Oorexx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/oorexx-devel
