On Sun, Nov 25, 2001 at 07:54:11PM -0500, Charles Bailey wrote:
> > Some alternatives:
Here's a thought. A good chunk of the problems involve wedging the
rich VMS env API into the narrow API of %ENV. To make matters worse,
its trying to work as much like everybody's else's %ENV as much as
possible.
These two things seem mutually exclusive. So let's seperate them.
You have %ENV which will strive for maximum compatibility and some
other API that strives for maximum richness.
print $ENV{FOO}; # prints the topmost FOO
$ENV{FOO} = 'mybar' # sets FOO on the process table, original value
# stored.
delete $ENV{FOO}; # places FOO='' in the process table, original
# value stored.
exists $ENV{FOO}; # always false if delete() has been called on
# this key.
When the program exits, all original values are restored or removed
from the process table as appropriate. I forget, does the process
table disappear automatically anyway?
The first step is writing up a module that can perform the full range
of VMS environment manipulation *without* using %ENV. Once that's
written, we can write a module on top of that which provides a tied
%ENV and we can play around with various behaviors much more easily.
Of course radically changing the behavior for VMS %ENV will break
backwards compatibility, but it seems it never was very well defined
in the first place. There's always "use unixish qw(%ENV)".
--
Michael G. Schwern <[EMAIL PROTECTED]> http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
Only mindless violence can raise my spirits now!
