Added Nicholas Clark as that is the name on VMS::Filespec.pm and Michael
Schwern says I should do that when discussing a module.
These aren't the only reasons we need a different way to test CRTL
features from Perl. The assumption in the code as written is that
the %ENV hash maps to logical names, which may or may not be the
case. We probably need some XS to really do this right, something
comparable to VMS::Filespec that is wired into the core and available
everywhere, even in miniperl. I'm thinking of something like
VMS::CRTL->feature_get() and VMS::CRTL->feature_set() as wrappers
around the C calls that query and set the C run-time features.
I do not know how to write such an XS and set it up to also be part
of a Perl distribution.
I just looked at the 8.2 CRTL documentation.
There are currently 19 feature settings that affect how the CRTL will
handle UNIX file specifications.
Of these, 11 also affect how VMS file specifications are handled.
This is out of a total documented 52 settings.
More are coming. Many of these are to implement changes in the CRTL to
be more compliant with X-OPEN, but are left as non-default options to
keep from breaking older code. Some of them are aggregates where
setting one implies setting others.
Since handling all that is beyond what I can do in the short term, this
is what I plan to do.
I can eventually put wrappers in VMS.C that do the feature_get and
feature_set, so that they override private methods in VMS::Filespec
under VMS. This is really needed for the feature_set, as VMS.C and some
other C code is keeping a static copy of the value, and the routines
to set the value will need to know to update it.
Note that being able to set the value does not mean that names
previously stored using a different setting will change their value, and
some settings are only looked at before the main() process starts.
On non-VMS systems, those private methods will use %ENV{} hashes to
simulate looking up the DECC$* values requesting the desired behavior.
I will first implement these that way and then move the code to VMS.C.
By doing that, the filespec.pm will be a little more up to date than it
is now.
In the mean time if a VMS user puts a DECC$ feature value in a DCL
symbol, things will get confused, and the only answer I can give is to
say not to do that.
Then I think I can figure out how to add methods that return or
optionally set aggregate modes, where Filespec.pm will have perl code
to set or return what filename mode Perl is in.
Using aggregate modes means that it is possible to set up DECC features
manually in ways that may not produce desired effects, so an aggregate
mode will only be returned as set if all the features that it knows
about are properly set.
This way it will be easier to tweak these features by modifying the perl
script instead of rebuilding a Perl executable every time a different
set needs to be specified to improve the UNIX compatibility modes.
Many of the DECC settings that affect how Perl will operate with the
CRTL, the modules written C do not have to know about, but the modules
written in Perl may need to.
The big ones are (and the ones I am implementing)
Case sensitivity. I have put in an override for the method in
filespec.pm to indicate the process setting for versions of VMS that
support it. (I have not verified that this works, as I am testing
the case preserved mode)
Case preservation. DECC feature.
Extended character sets in filenames. Several DECC feature settings.
UNIX pathname output and behavior requested. Several DECC features
settings.
POSIX-UNIX pathname output and behavior requested. (future VMS) This is
where symbolic links are implemented, and will essentially will imply
UNIX filename output and behavior, only RMS will be handling most of
the interpretation of the POSIX pathnames.
There is also the possibility of UNIX ONLY / VMS ONLY with POSIX
variants in the future. The problem is that I have not found out how to
get Perl to run in these modes with out POSIX, let alone with it.
I am still at this writing trying to get 5.8.7 to build with my changes,
and I have not figured out how to name these new modes.
I am planing on having them return 0 if the feature is not enabled.
-John
[EMAIL PROTECTED]
Personal Opinion Only
