From: Mark M. <mie...@gm...> - 2009-06-26 16:05:45
|
On Fri, Jun 26, 2009 at 8:49 AM, Rick McGuire<obj...@gm...> 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 |