TODO list (not in the order that I may get to them, and if someone gets
to them first, I certainly do not mind :-).
* VMS::Filespec::case_tolerant now reflects the true state of
case tolerance expected by the person running Perl.
Unfortunately several files and directories in Perl are being
created in the wrong case, and it is possible that many perl
programs in core are making now incorrect assumptions about
$^O = 'VMS'. And this includes one of the tests that is
assuming that case_tolerant will always return a 1 for VMS,
and I do not know how to fix that test.
* DCL command line length on 7.3-2 and later is now 8192 bytes,
and 1024 before that, with 4 bytes subtracted for internal Perl
use. Unfortunately previously Perl was using 6 of those bytes.
Currently it is using 5 of those bytes because I did not understand
what the checks were doing, so I did not put in a fix. Since the
only reference I found in core seemed to think that 256 bytes was a
limit on VMS this does not appear to be an immediate problem. But
there is a little more clean up work to be done. Based on how the
buffers are used would indicate that a buffer overrun may cause a Perl
program to crash, but not really allow a hacker to have any real fun.
A method to let Perl programs know what the limits are might be
useful.
* Need to verify there is a test for open("foo|") being run for VMS,
where foo is a perl script with a shebang path to the test version
of Perl and also one for the Alternate_shebang path when that is
configured, which it is for VMS.
* Improved handling of ODS-5 file specifications and support for
symbolic links both in UNIX and VMS format. This is know to require
fixes to several modules, so far ones that are known to need updates
are (as of a check of Perl 5.8.7)
lib/Cwd.pm lib/FindBin.pm
lib/ExtUtils/Command.pm lib/ExtUtils/Manifest.pm
lib/ExtUtils/MM_Unix.pm lib/ExtUtils/MM_VMS.pm
lib/File/Temp.pm lib/File/Spec/VMS.pm
lib/Pod/Perlvms.pod vms/perlvms.pod
ext/Cwd/t/cwd.t ext/File/Glob/t/basic.t
ext/POSIX/t/posix.t lib/AutoSplit.t
lib/blib.t lib/FindBin.t
lib/h2xs.t lib/ExtUtils/t/Command.t
lib/File/Spec/t/crossplatform.t
lib/File/Spec/t/Spec.t t/op/defins.t
The major issue with these is that they are either coded to expect
only ODS-2 limited file specifications, or that file specifications
will only show up in VMS format.
A few of them are internally translating VMS format to UNIX format
and back to VMS, and this has never been reliable for ODS-2 and the
broken cases are more visible on ODS-5. As these cases are found
(again to verify them, I already found them once) they need to be
added to the vmsify and unixify and Pathtools documentation to
demonstrate the limitations of using those routines.
Some are unexpected translating a VMS name to UNIX or the reverse.
The unexpected translation of a UNIX format name to a VMS format will
break some tests when the C library is in UNIX report mode.
Almost all the major changes needed are in Cwd and Pathtools, the
rest of the modules need minor edits and to know what mode the C
library is in on VMS.
* FOO:[000,000] is FOO:[000000] where all the directory characters are
numeric and there are only up to 6 of them, where only three may
exist on either side. Also they are generally only in octal.
vmsify() should produce 'foo:[000000]' and unixify() should produce
'/foo'. Neither vmsify() or rmsexpand() should produce the [000,000]
syntax.
* DKA100:[5953,9,0]FOO.TXT;1. is a VMS legal syntax for an existing file
that the file path will not fit in 255 characters when passed to an
application that can not handle the full length of paths. This is
known as DID abbreviation.
* LookAtWhatWeHave^!ThisIsAVery_long^.fi~[7254,30,0].txt;1 is a legal
VMS syntax for a file path that was still longer than 255 characters
after DID abbreviation. This is known as FID abbreviation.
* unixify should know how to expand such paths. I plan to have vmsify()
also expand those paths to their full length, even though some perl
programs may not handle the expanded paths. Currently neither
vmsify() or unixify() can handle these file specifications, so changes
in their behavior should not adversely affect existing programs with
the filenames they currently work on.
* It is possible but unlikely that rmsexpand() could currently produce
DID and FID filenames. Because of where I am finding rmsexpand()
used, It will by default produce a VMS file specification that will
fit in 255 characters.
* I have a new feature note for VMS 7.2 that states that '?' is now a
wildcard character and as such should not be translated to '%' from
a UNIX specification. Since '%' is still not a UNIX wild card
character to my knowledge, it again is something where translating a
VMS name to UNIX syntax and back can slightly change the meaning of
the specification.
* Various filename translation issues:
If DECC$UNIX_PATH_BEFORE_LOGNAME is not set, then to prevent
misunderstandings, '[.lib]' should translate to './lib/' instead
of 'lib/', and the tests updated for this. VMS 'foo.' is a UNIX
'foo', a UNIX 'foo.' is a VMS 'foo^.'.
* The VMS HP/Compaq/DEC C compiler can produce shortened (crc mangled)
symbol names for public symbols longer than 31 characters. Of course
the dynamic loader in Perl on VMS can not handle them.
* Bash shell support. This needs lots of work. Pipes need to be fixed.
Environment variable handling needs to be changed. The bash shell
can only see environment variable set in the C library environment
table where Perl usually will not put them. Which also means many
things may need to use a different method for accessing logical names
in that mode than they are currently using. It is likely a new core
module to do logical name handling will be needed. I have received
a copy of one that I have not had time to look at.
* SMG based readline API support (if it is not already done that way)
This allows fixing the Perl debugger to behave on a VMS Decterm the
same way it behaves on a UNIX xterm where the debugger I/O is on
a different terminal window then the program I/O.
* The perl5db_pids feature does not work on VMS unless Perl is being run
under the bash shell.
* MakeMaker is generating a false command which breaks rebuilding perl
on VMS unless an alias is created that causes false to return a
success. The intent of the false command is to indicate a build
failure to the caller of the makefile. But because of the way that
the VMS shell handles such errors, it totally aborts the build.
If MakeMaker sets up the false command to work on VMS as it does on
other perls, then the DCL build procedures for Perl need to be fixed
to expect that behavior.
It appears to me that even though it is more work for VMS, that this
should be done so that MakeMaker does not have to tread VMS very
differently in this case.
* REALCLEAN target has many syntax errors while it is running and still
leaves some *_OLD files behind. IMHO, the syntax errors indicate that
the rules for the target are not being created correctly.
* Make maker really needs to key off of the make program being 'MMS' or
'MMK', as when the make program is 'make' then UNIX behavior will be
expected. But that will probably not be an issue until after support
for the GNV bash shell is working.
* Documentation update about timezone issues, which may not be VMS
specific. If you are changing to/from DST with a non-standard
timezone, you should use the ZIC utility or equivalent for your
platform to create a new timezone to match what you are doing or some
programs that work with time values may produce incorrect results, and
this includes Perl scripts.
* Pathtools can not handle [.foo^..bar.more.-] which translates to UNIX
'foo./bar/more/..' and is effectively [.foo^.bar] or 'foo./bar/'. And
so far I do not know how to fix it.
I have probably left a few things out of this list, but it is long
enough already.
-John
[EMAIL PROTECTED]
Personal Opinion Only
