Ah, was was just taking a look at this myself, and couldn't figure out
why the searchPath() code didn't appear to be working. This is really
a bug in the hasDirectory() method rather than being an invalid test.
This was basically just a lazy check to screen out non-relative
directory specifications. It should be rejecting things like "/foo",
"./foo", "../", or "~/foo". I'll take a look at fixing this tonight
if nobody beats me to it.
Rick
On Fri, Jun 26, 2009 at 12:05 PM, Mark Miesfeld<miesf...@gmail.com> wrote:
> On Fri, Jun 26, 2009 at 8:49 AM, Rick McGuire<object.r...@gmail.com> wrote:
>
>> Rick has just been VERY busy, and not had a chance to investigate this.
>
> Aha, I was VERY busy yesterday, today not so much.
>
>>>
>>> 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.
>
> Well, I only called it a bug on Windows because his example fails on 3.2.0.
>
> Here's why / where it fails on Linux.
>
> In interpreter/platform/unix/SysFileSystem.cpp around line 485, after
>
> if (checkCurrentFile(tempName, resolvedName))
> {
> return true;
> }
>
> which fails because the current working directory is home, we have this:
>
> // we don't do path searches if there's directory information in the name
> if (!hasDirectory(tempName))
> {
> // go search along the path
> if (searchPath(tempName, path, resolvedName))
> {
> return true;
> }
> }
>
> dirB/progB fails the !hasDirectory() test so it is never found.
>
> The restriction seems artificial to me. When I remove the
> hasDirectory() test then the example program works on both Windows and
> Linux.
>
> Which as I said is sort of the way I think it should work. It's just
> that it never worked that way in the past.
>
> I'm in favor of removing the restriction. In the next couple of days
> when you get a chance to look at it, let me know what you think.
>
> --
> 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
