Re: [patch@35050] replace pathify_dirspec in VMS with new version

Craig A. Berry wrote:
> 
> On Dec 7, 2008, at 12:46 PM, John E. Malmberg wrote:
> 
>> Point taken,
>>
>> Attached is vms/ext/filespec.t that changes those tests to be passing.
> 
> The documentation for VMS::Filespec::pathify says, "the file type and 
> version, if specified, must be .DIR;1. For compatibility with Unix 
> usage, the type and version may also be omitted."  The tests have 
> enforced this behavior since before 5.004.  You're proposing to change 
> the behavior so that a file type that is not .DIR is no longer 
> considered a file type at all and the dot would then be considered part 
> of the filename rather than the start of the type field.  That could 
> easily break existing code and doesn't seem to me like the way to go.

This is for UNIX format file specifications, which normally should not 
have a .dir on them when they are directories.

The new behavior is not inconsistent with the existing documentation, 
except that the old routine does not work for EFS characters.

> Now if the dot is escaped and is thus unambiguously just an actual dot 
> rather than a directory or file type delimiter that's a different 
> story.  We should support and test for those cases, something like:
> 
> __path_^.actualdot pathify __path_.actualdot/

The '^' escape character is only present on VMS format file 
specifications.  With out any directory delimiter characters present, 
pathify assumes that this is a UNIX directory.

With a Unix directory syntax if ".DIR" is not present, the behavior of 
pathify would normally to be just put a '/' on the specification. 
Removing the ".dir" is needed because it may be present.

The following demonstrates the existing behavior is inconsistent:

$ perl -v

This is perl, v5.10.0 built for VMS_AXP

$ perl -e "print VMS::Filespec::vmsify('foo/bar./')"
[.foo.bar_]
$

$ perl -e "print VMS::Filespec::vmspath('foo/bar.')"
$
[Nothing output]

Those two sample one liners should have produced the same output.

$ define decc$efs_charset ENABLE
$ perl -e "print VMS::Filespec::vmsify('foo/bar./')"
[.foo.bar^.]

$ perl -e "print VMS::Filespec::vmspath('foo/bar.')"
$
[Nothing output]

As should these two examples.

So while it is change in behavior, the older tested behavior appears to 
be incorrect as it will cause file specifications that are accepted in 
other routines to be rejected.

I do not think this would be noticed in existing programs other than the 
test routines because such file specifications are rare on a VMS system, 
and that if someone had encountered one of them, they would have had to 
modify their perl program to not use pathify, unixpath, or vmspath.

-John
[email protected]
Personal Opinion Only