Craig A. Berry wrote:
At 1:40 PM -0400 10/22/05, John E. Malmberg wrote:
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
Shouldn't case tolerant mean we don't care what case they're created
in? And isn't it unzip, tar, etc. rather than Perl that determines
what case the filenames are created with?
It is the setting of case_tolerant = 0 where exact case is wanted that
is the problem. The gnutar utility in GNV should be unpacking Perl with
the correct case.
It appears that the Configure.COM mms/mmk procedures are apparently
creating some files and directories in uppercase.
A I prefer to run in a case blind mode, I have not tried to find all the
places. A simple test showed that some directories were in the wrong case.
It also may be desirable to have a script that repairs the case of a
perl installation.
Someone that needs strict case sensitivity instead of just case
preserved may be motivated to do the detective work and find all the
cases, now that Perl will try to follow the process setting.
Pathtools and other core modules still do not support the case preserved
mode either.
* 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.
The xsubpp processor that converts .XS into .c when building a Perl
extension needs to know what the symbol names will be from within
Perl. That's why it has its own symbol shortening algorithm that has
been working just fine for years for extension building. There are
of course still potential issues when dealing with external
libraries, and getting support for the C++ compiler working may also
involve looking at this because of its own name mangling features.
It is more of a cover all the basis issue than a pressing need. The
dlsym() routine in the CRTL also can not handle the shortened symbols.
The CRC method while producing an slightly unreadable symbol can handle
longer and more complex names than the current Perl XS algorithm with
out running into duplicate symbols.
If you want to embed Perl into Java on VMS, you need to use the CRC
method to generate the symbol names for Java to see. So that is another
reason for Perl to know how to encode/decode that method.
* Bash shell support. This needs lots of work. Pipes need to be fixed.
In principle, just replacing my_popen() and my_pclose() in vms/vms.c
with another implementation would be all that's needed. Also,
Perl_my_waitpid() would need some work. I think the choice of a pipe
implementation should be a configure-time option, though, as folks on
older versions of VMS will probably be best served by what we've got
now, and in fact there's no proof as yet that currently available
alternatives are better.
Actually what Perl has is not too bad, and is much better than the pipe
implementation in the C library. I recently used what I had learned
about how perl works to implement a fix to Bash to eliminate the RWMBX
hangs while running configure scripts.
What I need to do is find out where the extra newlines are being added,
because when I recreated the algorithm for bash, I did not end up with
extra new lines. I also do not seem to be having the problem with
truncated lines either.
The my_popen() stuff just looks a lot worse that it is.
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.
If the logical name PERL_ENV_TABLES is defined to CRTL_ENV at
start-up time, then Perl's %ENV will map to the CRTL environ array
and will not use logical names. If you have a way to determine at
start-up that you're running under bash, you could hard-wire this or
at least change the default in that environment. See the following
docs on how this works:
http://perldoc.perl.org/perlvms.html#Perl-variables
Yes, I am just documenting the issues so that they are not forgotten and
maybe someone will fix them before I have to :-)
* The perl5db_pids feature does not work on VMS unless Perl is being run
under the bash shell.
The basic issue, IIRC, is that the debugger does not expect an %ENV
element to persist after program exit the way supervisor mode logical names do.
Yes, and a pid is not reused on UNIX as it is on VMS. But getting the
DECterm support would be a real help.
-John
[EMAIL PROTECTED]
Personal Opinion Only
