Craig A. Berry wrote:
At 8:31 AM -0500 8/24/07, John E. Malmberg wrote:
Jos I. Boumans wrote:
Since MLC uses Module::Load, wouldn't it just be an easier fix to
always unixify paths on VMS?
How does this patch look for you?
--- local/oss/module-load/lib/Module/Load.pm (revision 2064)
+++ local/oss/module-load/lib/Module/Load.pm (revision 2065)
+ $file = VMS::Filespec::unixify($file) if $^O eq 'VMS';
Yes, it looks like it will work.
So are you saying I should roll back #31746:
http://public.activestate.com/cgi-bin/perlbrowse/p/31746
and apply Jos's patch instead?
No. Joe's patch works around the issue for all versions of Perl only
for the CPAN module. It does not work around the issue for random
programs that may use the require $filename syntax of a module that
could also be in a require $module_name statement somewhere else
Another issue has shown up with pp_require. It seems that if you
are in directory foo, and it has a parent directory in @INC, you can
>> do a require foo::bar and a require of bar.pm, and while they are
the same file, this will not be detected by pp_require, and both
>> will be loaded.
Does this happen on other platforms or just VMS?
Actually it was encountered on UNIX. I have not seen a real example of
it on VMS.
I do not see how this can be fixed except with a lot more code in
pp_require to check the parent directory.
That seems unlikely to happen before 5.10.
And those checks may fail on VMS because "foo/" on VMS can be
multiple directories, such as "tom/", "dick/" and "harry/", so
checking parent directory of that file will return one of those,
>> and not the "foo/" needed for the matching the key to %INC.
Using a different syntax for the keys to %INC could break existing code.
About the only way to avoid this would be for the key to be based on the
inode and dev_t members, and I know there would likely be a problem with
that on 32 bit VMS builds.
It may be just better to document this as a limitation of the "require"
>>statement.
-John
[EMAIL PROTECTED]
Personal Opinion Only
