Craig A. Berry wrote:
John has recently added:
vms_realpath
vms_realname
vms_case_tolerant
to VMS::Filespec. We definitely need what these things do, but as
other dust has settled I've given some thought to certain behaviors
and interface considerations and have a few minor reservations.
Apologies for not paying closer attention earlier when it would have
been a better time to kick around the design.
A quick summary of what these new functions are for is that
vms_realname calls LIB$FID_TO_NAME to get the full absolute path of a
file with any symbolic links resolved and returns the result in VMS
syntax. vms_realpath is just a wrapper around vms_realname that
returns the path in UNIX syntax, or at least that's what it does if
the CRTL realpath isn't doing what it's supposed to do.
vms_case_tolerant is based on JPI$_CASE_LOOKUP_PERM and
JPI$_CASE_LOOKUP_IMAGE; if either indicates case sensitivity it
returns false, and otherwise returns true.
1.) The first nit is that vms_realname and vms_realpath do not honor
the setting (or lack thereof) of DECC$EFS_CASE_PRESERVE.
Specifically, when that setting is off (as it is by default) path
names do not get lower cased as they do by everything else in the
CRTL and Perl. I think they should.
That makes sense. The getcwd() routine also needs this as it is
currently returning exact case.
2.) Another thing that I think will be surprising about vms_realname
and vms_realpath is that they translate concealed logical names.
Compare rmsexpand:
$ perl -e "print VMS::Filespec::rmsexpand('d0:[craig.perl]perl.c');"
d0:[craig.perl]perl.c
with vms_realname:
$ perl -e "print VMS::Filespec::vms_realname('d0:[craig.perl]perl.c');"
DISK$ALPHASYS:[CRAIG.perl]perl.c
So vms_realname has done the equivalent of passing NO_CONCEAL as the
fifth argument to F$PARSE. Perhaps there are cases where we would
want that behavior, but it seems inconsistent with everything else
I'm aware of to do it when it hasn't been explicitly requested. I
have a feeling it is just an accidental side effect of calling
LIB$FID_TO_NAME, and we should probably try to work around that.
This is intentional, vms_realname/vms_realpath return the absolute path
of what in UNIX terms the primary link of the file from the point of the
file system, not the path given.
That is what the UNIX realpath does, it resolves all symbolic links in
the path. So the VMS equivalent should remove all logical names from
the path. LIB$FID_TO_NAME is the closest equivalent to the UNIX
realpath that VMS has.
I am expecting that these routines will be used in the Pathtools module.
The past implementation of the abs_path on VMS using RMSEXPAND has been
different in behavior than the UNIX equivalent, especially in the
handling of non-existant files or directories.
There should be some tests added for the error cases on all platforms.
I think it that were done earlier, the inconsistencies in the VMS
implementation as compared to UNIX would have been noticed.
3.) Finally, the thing that really bothers me is the "vms_" prefix in
the new functions. We're already in the VMS::Filespec namespace, so
the only reason to have "vms" in the name of one of the functions is
to indicate that the resulting filespec is in VMS syntax. For
example, we already have vmsify and vmspath. By that measure,
vms_realpath does the opposite of what its name tells you it will do
because it returns a UNIX syntax path. To be consistent with what
the VMS::Filespec namespace is about, I think we should rename these
functions as follows:
vms_realpath --> unixrealpath
vms_realname --> vmsrealpath
I do not have a problem with that, I put the vms_ prefix on them only to
prevent issues with a realpath() being exposed by another module that
was also in scope.
We could also export these by default (as we do with all the existing
VMS::Filespec functions) since I think the chance of collision with
these names is slight.
vms_case_tolerant is a bit different since it doesn't return a
filespec, but I think case_tolerant_process would be a better name
that would make its purpose clearer. I also *don't* think it should
be exported by default, i.e., it could be in @EXPORT_OK but should
not be in @EXPORT.
I am ok with a different name. My original intention was for it to
override the File::Spec->case_tolerant routine.
My intention is also for there to be a way for perl to specify if it
wants to change the process to be case_tolerant while it is running.
With the exception of #2 above (the NO_CONCEAL) problem, these are
all pretty trivial changes and I think I will go ahead and try to get
them done before 5.10, but I wanted to get the rationale out in
public. So far the new functions have not been in any released
version of anything, so the time to normalize the names is now.
As these are probably for use only by pathtools, it may make sense only
to have the updated versions of them import them.
I am also coming to the conclusion after the discussion on the
perl5-porters list, that the vms symlink() function should internally
translate the target to UNIX format unless:
1. DECC$FILENAME_REPORT_UNIX is active.
2. DECC$FILENAME_UNIX_ONLY is active.
3. DECC$POSIX_COMPLIANT_PATHNAMES is non-zero.
I think that this would make the behavior match what the typical perl
program that is using symlink expects.
-John
[EMAIL PROTECTED]
Personal Opinion Only
