Ken Williams wrote:
On Nov 24, 2007, at 6:04 PM, Craig A. Berry wrote:
I'll let John check on whether his Cwd change look good, but I see two
VMS -related patches to PathTools in blead that are not in your svn
repository:
I am trying to get caught back up, but I have other things that I need
to do also.
http://public.activestate.com/cgi-bin/perlbrowse/p/31431
http://public.activestate.com/cgi-bin/perlbrowse/p/31432
Thanks, I've applied them now.
Regarding the second patch, it seems like we should find a way to make
the test actually happen on VMS; the point of the test is to make sure
we don't muddle with %ENV, something it would seem like we should be
doubly vigilant on VMS about.
Is it permissible on VMS for us to at least check that the actual keys
of %ENV haven't changed before & after the call?
Not really.
There are two problems.
1. By default, what %ENV maps to on VMS are not really environment
variables, but are logical names. From a UNIX point of view, logical
names are more like either symbolic links or mount points in how they
are interpreted by the file system.
%ENV by default reads logical names that are both local to the process
and those that are shared globally to all processes.
So on VMS, %ENV can return a very large hash. The equivalent on UNIX
would be it returning all symbolic links and mount points that are
visible to the running process.
Logical names are used sometimes to convey information between
processes, on a dynamic basis.
So it is really impossible to take a snapshot of the all the logical
names that %ENV can read and expect them to be be the same at another
moment in time. The keys for %ENV may or may not be different depending
on what else is going on with the system.
Even worse, on perl %ENV can modify the shared logical names, and doing
so will cause the same effect on VMS as a privileged process on UNIX
made changes to mount points and symbolic links on UNIX.
So saving and restoring the %ENV on VMS is something that is almost
guaranteed to cause a problem if the process is privileged enough.
There are already warnings about this in POD. I think they are in VMS
specific section, but they should be in the %ENV documentation so that
other perl programmers should realize that.
2. In addition to the logical name table, %ENV on VMS by default reads
the local environment values.
A number of those local environment variables on VMS are magic, and
these probably need to be identified and documented in the porting pod.
What this means is that if environment variables did not exist, local
copies are dynamically created when they are read through the $ENV call.
So %ENV may or may not show them, but $ENV will return a value.
It is currently not possible in Perl on VMS to determine if these
environment variables existed out side of the current perl process.
So there is not a way to restore the original condition of those
environment variables.
If the real or magic environment variables are changed in Perl on VMS,
by default, it will create a logical name, which unlike real environment
variables, will be persistent beyond the life of perl.
There are alternate modes to the %ENV hash on VMS. I am not sure how
well they work, or if the smoke tests exercise them. Running Perl under
VMS will probably require one of the alternate modes.
As a note to the about 100+ subscribers to the VMSPERL mailing list,
even if you are not up to writing patches to the perl code, getting the
documentation as accurate and clear as possible is a way to contribute.
-John
[EMAIL PROTECTED]
Personal Opinion Only
