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.
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.
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
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.
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.
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
