Rethink EFS in File::Spec::VMS.

ae5a807c7dcf made extensive changes to File::Spec on VMS, nominally
to support Extended Filename Syntax (EFS).  The idea behind the
changes was that with EFS in effect, the File::Spec functions can
guess at whether incoming file specifications are in Unix format
or VMS format and provide output in the same format as the input.

This principle is in some ways desireable in that round-trip
conversions do have the potential to lose information and it
sounds like a nice bit of DWIMmery. However, in practice it leads
to its being a crap shoot what format you'll get back, and in some
really important cases (such as MakeMaker's assembly of paths for
external build utilities) you really have to know which syntax you
have and you may really have to have native syntax, which has
always been the default.

It's also impossible to guess in some of the more common use cases,
such as a splitdir followed by catdir, where catdir has no way of
knowing what delimiters were discarded by splitdir, and thus no
hints about what syntax the original path was in.

Plus there were numerous problems with the implementation, which
broke the build when EFS was in effect and didn't pass very many
of its own tests (which it had inadvertently disabled, since fixed
in 06ecd9c7d6f).

Plus EFS isn't primarily about Unix syntax versus VMS syntax but
about allowing additional characters, such as multiple dots in
filenames or any dots in directory names.  The only real difference
for the File::Spec functions should be that they now need to avoid
splitting on traditional delimiters if those characters are escaped
with the caret (^) character.

So revert most of ae5a807c7dcf, and sprinkle negative look-behind
assertions liberally so that we correctly recognize when
traditional delimiters have been escaped and are not being used
as delimiters.

The partial support for Unix reporting mode (where we explicitly
request that output file specifications are in Unix format
regardless of input format) is left in place.  It's somewhat less
partial than it was, but still incomplete.

0 files changed, 0 insertions, 0 deletions