Craig A. Berry wrote:
At 1:02 PM -0600 12/8/07, John E. Malmberg wrote:
Craig A. Berry wrote:
The getcwd() routine also needs this as it is currently returning exact case.
Hmm. Isn't that just using the CRTL getcwd()?
Possibly, I only noticed it because one of the new core routines was
comparing the output of getcwd() with a directory returned by the some
other source, and it failed because of the case difference.
More tests are always welcome. There is a lot of work in progress on
PathTools and we'll need to contribute to that, but this will now
have to be post 5.10.0, unfortunately.
Yes, I think first we need to add the logical name handling and decc$
feature handling to be part of VMS. The older versions of VMS use
logical names to control the features instead of the decc$ features, so
we need those as a fallback.
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.
As of #32601 it's case_tolerant_process and can be exported if
requested but is not exported by default.
Hmm, since the Pathtools module must test to see if the routine exists,
will that be a problem?
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.
Yes, it occurred to me that we would eventually want to set as well
as get this property. For now it's read-only with no arguments, but
it shouldn't break the interface to add an optional boolean argument
somewhere down the road, the value of which means, when true, turn on
case tolerance (disable case sensitivity) and when false, turn off
case tolerance (enable case sensitivity). Changing this function
will probably be the least of our problems if we try to get Perl
working in a case sensitive environment.
Previous discussions on Perl 5 Porters indicate that it would be
acceptable for case_tolerant to accept an argument. Microsoft NTFS
volumes can also be case_tolerant. I am not sure if it is a volume,
folder, or process property though.
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.
That sounds about right. I think what we have now for shipping with
5.10.0 will do the right thing if you talk to it nicely and have read
chapter 12 of the CRTL manual and understand how symbolic links work
on VMS. We can surely improve default behavior and corner cases for
5.10.1.
The current plan is to release 5.10.0 on December 18, which is Perl's
20th birthday.
I probably will not be too active with changes until January.
I will be trying to find out what happened with GNV 2.x on 8.3, as I
have discovered that the gnutar is not able to pipe gzip as the older
version could. Also in attempting to build the current gnutar, I am not
able to get configure steps to run that I could using my fixed up bash
on GNV 1.x on VMS 8.2, which is what should be in the GNV 2.x release.
We also need some more tests in Archive::Tar. It is what is causing the
remaining module build test to fail. It creates a tarball that it can
not read, and I can not read on VMS with any of the tar archives that I
have.
-John
[EMAIL PROTECTED]
Personal Opinion Only