Unless things have changed much in the last nine months, I surmise from the mail below
that Perl isn't promising much, at present, in the way of support for extended file
specification syntax. That about right?
I tried something involving periods that weren't delimiters, in PERL5LIB among other
things, and it looks to me like it didn't do too well with that:
$ SHOW LOGICAL PERL5LIB
"PERL5LIB" = "$1$DUA1400:[RE_TOEDEL.SAS^.9^.1.INSTALL.PGM]"
...
Can't locate constants.pm in @INC (@INC contains:
/$1$DUA1400/RE_TOEDEL/SAS^/9^/1/INSTALL/PGM perl_root:[lib.VMS_AXP.5_6_1]
perl_root:[lib] perl_root:[lib.site_ perl.VMS_AXP] perl_root:[lib.site_perl]
/perl_root/lib/site_perl .)
Looks to me like it didn't correctly translate PERL5LIB from VMS to Unix syntax, which
would be one case of this part of your mail:
> There are lots of places in vms.c that do their own filespec
> parsing based on the traditional delimiters (<>[]:). It's
> entirely possible for legal ODS-5 filespecs to get parsed
> incorrectly. Not sure how to handle that.
I'm still on Perl 5.6.1, but it sounds like things haven't moved forward much in that
area. Not complaining, mind you -- I know you don't need that, you need people to
step forward and do things -- just asking whether I'm right about this.
Thanks. / Tom Edelson
P.S. I thought it might work if I defined PERL5LIB correctly in Unix syntax myself,
but it looks like it didn't. Different example:
$ dir $1$DUA1400:[RE_TOEDEL.DIR^.WITH^.DOTS]
Directory $1$DUA1400:[RE_TOEDEL.DIR^.WITH^.DOTS]
mymodule.pm;2
Total of 1 file.
$ show logi perl5lib
"PERL5LIB" = "/$1$DUA1400/RE_TOEDEL/DIR^.WITH^.DOTS" (LNM$PROCESS_TABLE)
$ perl test.pl
Can't locate mymodule.pm in @INC (@INC contains: /$1$DUA1400/RE_TOEDEL/DIR^.WITH
^.DOTS perl_root:[lib.VMS_AXP.5_6_1] perl_root:[lib] perl_root:[lib.site_perl.VM
S_AXP] perl_root:[lib.site_perl] /perl_root/lib/site_perl .) at test.pl line 4.
> -----Original Message-----
> From: Craig A. Berry [mailto:[EMAIL PROTECTED]
> Sent: Friday, November 22, 2002 1:29 PM
> To: Carl Friedberg
> Cc: [EMAIL PROTECTED]
> Subject: Re: FW: Hoff on ODS-5 system disks and case issues
>
>
> Carl,
>
> Thanks for the reference. I am aware of the existence of the
> documentation that Hoff mentions and have some familiarity
> with -- though not necessarily complete command of -- its
> contents. Acting on it is another matter entirely. There
> are a number of things that need to be done in Perl to catch
> up with current CRTL capabilities and ODS-5 generally.
>
> For starters, there is the way vmstar works on ODS-5 volumes.
> By default, recent versions of it allow formerly illegal
> characters in directory and file specs and escape them with
> the caret (^) per ODS-5 guidelines. So, for example, when
> you unpack the Perl source tarball your top-level Perl
> directory will be [.perl-5^.8^.0]. In order to even set
> default to that you will need to have extended parse style
> enabled (not to mention better than average facility with the
> top row of the keyboard!), but extended parse causes the
> build of the Encode extension to fail, no doubt due to some
> conflicting assumptions about legal characters and/or case.
> The Encode build needs to be fixed to work in all
> combinations of disk structure level and parse style.
>
> There is the -o | /ODS2 option available in vmstar to force
> legal ODS-2 names, and that will dodge the foregoing
> problems. However, it needlessly upcases the filespecs in
> addition to translating illegal characters. It would be nice
> to have it preserve case but perform the other translations
> like unzip does.
>
> Those are all just issues that come up getting Perl to build.
> There are many places in the test suite and even in some
> core modules where filename case is assumed to be lower (and
> even forced to be). Each of these will need to be addressed
> in a way that continues to work for ODS-2 but also handles
> case properly for ODS-5. In general, the basic assumption is
> changing from "filename case is always lower" to "filename
> case may be mixed and should be preserved where possible but
> case preservation cannot be assumed or required."
>
> We need to look into honoring DECC$xxx logical names,
> especially DECC$ARGV_PARSE_STYLE and DECC$EFS_xxx. It would
> be nice not to have to quote everything on the command line
> and to preserve filename case when we can.
>
> Perl's utime() implementation should handle the true access
> time field available on ODS-5 volumes rather than conflating
> it with the modification time as is necessary on ODS-2.
>
> We need to figure out if an ODS-5 volume with hard links
> enabled can support what symbolic links are expected to do in
> Perl. Then we need to be able to configure for it and have a
> way to test for it on a per-volume basis and change all the
> tests that assume VMS can't do it.
>
> Using NAML rather than NAM blocks when parsing filespecs
> would allow us to handle paths longer than 255 characters.
>
> There are lots of places in vms.c that do their own filespec
> parsing based on the traditional delimiters (<>[]:). It's
> entirely possible for legal ODS-5 filespecs to get parsed
> incorrectly. Not sure how to handle that.
>
> OK, I've worn myself out just making the list, which I'm sure
> isn't even complete. Anyone want to get to work?
>
> At 1:09 PM -0500 11/20/02, Carl Friedberg wrote:
> >This note is on DecuServe (eisner.decus.org) from Hoff in
> response to
> >an issue I've encountered running an ODS-5 system disk on VMS 7-3.1
> >
> >Note his comments about CRTL documentation, please :-( :-) (it's the
> >good news and the bad news).
> >
> >Carl
> >
> >-----Original Message-----
>
> <snipped>
> --
> ________________________________________
> Craig A. Berry
> mailto:[EMAIL PROTECTED]
>
> "... getting out of a sonnet is much more
> difficult than getting in."
> Brad Leithauser
>
