Ken Williams wrote:
>
> On Sep 12, 2005, at 11:12 PM, John E. Malmberg wrote:
>
>> It looks like I am finally close to starting to get the file spec
>> handling in Perl up to speed with current VMS versions.
>>
>>
>> In File::Spec::VMS, would it be appropriate to use a syntax like
>> below to switch VMS into case sensitive mode if the underlying
>> version of VMS & Perl supported it?
>>
>> case_tolerant=0
>>
>> VMS, and a few others also need a method to set/indicate the status
>> of case preserved.
>
>
> We could certainly let the case_tolerant value be mutable, and add a
> case_preserving attribute as well. That would be pretty easy, but
> still perhaps not powerful enough, because some systems (OS X) can
> simultaneously mount some filesystems that are case-sensitive and
> others that aren't. File::Spec's model of never consulting the
> filesystem is a little bit unhelpful in this case.
It is the same on OpenVMS. The older ODS-2 file system is aways case
insensitive and returns files in upper case only. There is code in the
VMS specific parts of Perl that make it look like lower case to be more
UNIXy.
It is turning off that lowercasing code that I need the case preserved
method to indicate and set.
I am not sure how to change vms.c to accept the new value for
case_tolerant. If I can find out how to do that, I can easily make the
other changes.
> Let's just add the mutable attributes for now, and we can ruminate a
> little on the tougher case.
I am assuming that if someone changes the defaults for a platform that
they will accept the consequences, or they will need to document the
restrictions. This will make some of the testing more complex.
I have several other file system attributes that Perl scripts may need
to know about, as they may be changeable and some samples are below:
I want to first do the case sensitivity, and then work on the rest in
stages.
Filename (no path) size: 255 characters.
Filename with path size: 255 | 1024 actual characters, 4096 with escape
characters for to prevent confusion with delimiters.
Extended characters in pathnames: The traditional VMS mode only allowed
[0..9],[A..Z],[-$_] with one period and prohibited file names starting
with '-'. The new set allows any character, including UNICODE, except
'*' to be in a pathname. The '^' character in a VMS pathname treated
sort of like a '\' in a UNIX string.
One thing that I do not know how to do is fix the cannonpath method to
work with [.foo^..bar] which in UNIX would be "foo./bar/" and still have
[.foo^..bar.more..] reduce to [.foo^..bar].
Also the following are legal syntaxes that may need to be processed:
[nnn,nnn] where n is numeric is equivalent to [nnnnnn] - Just remove the
comma, but the next one is more tricky.
[nnnnn,nnnnn,nnnnn]file.name, where n is numeric. This is a
compatibility mode for passing pathnames that are longer than 255
characters to routines that can not handle them. Unless a large enough
buffer [4096] is available, this name can not be translated to a UNIX
file specification.
Another attribute is if the filenames are returned as UNIX format or
native format from routines by default.
And still another is that if input filenames should be presumed to be
UNIX format or native.
VMS "foo." should translate to UNIX "foo", and with extended characters
enabled, UNIX "foo." should translate to VMS "foo^."
Unfortunately there are also more attributes that seem to show up in
corner tests where the behavior change in VMS to pass the test may not
be one that the Perl script user would want associated with other
attributes, which prevents some simplification.
When hard links are enabled on VMS at least one Perl test that is no
longer skipped expects the umask file protection to behave like UNIX
instead of like VMS.
-John
[EMAIL PROTECTED]
Personal Opinion Only
