Re: Better way to handle Unix compatibility modes must be found

On Apr 2, 2009, at 9:33 AM, John E. Malmberg wrote:

> Michael G Schwern wrote:
>> John E. Malmberg wrote:
>>> Are you going to have time to look at the patches that I submitted  
>>> to
>>> MakeMaker and Test::Simple?
>>>
>>> These are to support VMS when the DECC$FILENAME_UNIX_REPORT and
>>> DECC$EFS_CHARSET and related options are active.
>>>
>>> These options make Perl on VMS look more like Unix, including  
>>> returning
>>> filenames in Unix syntax.  Path tools has already been updated to  
>>> work
>>> in this mode.
>> I had a look at this, and I can't apply it.  It was bad enough  
>> having special
>> case code for VMS, now there's three different styles of VMS to be  
>> considered.

I had a similar reaction when I first saw it, but no one has suggested  
-- much less implemented -- anything else that actually works.  If you  
have a better solution, please speak up.

>> But this diff here illustrates the real problem:
>> -    is( $mm->{INSTALLVENDORMAN1DIR}, File::Spec- 
>> >catdir('foo','bar'),
>> +    my $expect = File::Spec->catdir('foo','bar');
>> +    $expect = VMS::Filespec::vmspath($expect) if $Is_VMS;
>> +    is( $mm->{INSTALLVENDORMAN1DIR}, $expect,
>>                      'installvendorman1dir (in %Config) not  
>> modified' );
>> Now every call to File::Spec, which is supposed to generate a  
>> portable path,
>> has to have extra code tacked onto the end to do more work.  If  
>> that's
>> necessary then File::Spec::VMS should be doing it.
>
> File::Spec::VMS traditionally has not generated a portable path.

It depends on whether portable means native to the platform you are  
running on or something generic that can work on any platform.

>> In conclusion, this should all be built into File::Spec::VMS.

That's logically impossible, for reasons that John explained.  To  
simplify a bit, File::Spec can reasonably be made to know whether it's  
expected to return results in native format or Unix format.  It cannot  
reasonably be made to know that it is being called from a spot in  
MakeMaker that must produce a native format filespec that will be seen  
by a native utility regardless of what mode Perl is in.

> It is only a small set of Perl programs that have benefited from it  
> converting some file specifications to VMS format.  I have found  
> more cases of programs that have required that VMS specific code be  
> added to them to compensate for this conversion in one way or  
> another than I have found programs actually expect it and need it to  
> happen.

> It is only the case where something is building a VMS specific Make  
> script or building a DCL command file that a filename needs to  
> specifically be converted to VMS path syntax.

That's probably 90% true now.  It was closer to 0% true in the dawn of  
time, when File::Spec::VMS::catdir first returned a native format  
spec.  There wasn't really any choice about that at the time.  The  
CRTL did not understand Unix format filespecs and there were lots of  
other things it didn't do that had to be implemented via native  
services.  There are more choices now, which does make things  
complicated.

________________________________________
Craig A. Berry
mailto:[email protected]

"... getting out of a sonnet is much more
  difficult than getting in."
                  Brad Leithauser