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
