At 6:06 PM +0000 2/22/08, Nicholas Clark wrote:
>On Thu, Feb 21, 2008 at 11:09:10AM -0700, Jim Cromie wrote:
>
>> + # now add in %env mods before we spawn the $runperl process
>
>Does this have horrible side effects on VMS?
>
> > + local %ENV = %ENV;
By design, it makes your program the horrible side effect rather than
risking damage to the environment:
$ perl -e "local %ENV = %ENV;"
Can't make list assignment to %ENV on this system at -e line 1.
Can't make list assignment to %ENV on this system at -e line 1.
%SYSTEM-F-ABORT, abort
Not sure why it says that twice.
>(context being that it would be used to undo the following:)
>
>> + $ENV{$_} = $args{env}{$_} foreach keys %{$args{env}};
>> +
>> if ($tainted) {
>> # We will assume that if you're running under -T, you really mean to
>> # run a fresh perl, so we'll brute force launder everything for you
>
>for %ENV, to include VMS, is the only way to be safe some manual
>"local"isation, by recording the state (!exists vs !defined vs value) for
>each %ENV key we want to change, and then per-key restoring them afterwards?
>
Something like that can be made to work for most cases. But I missed
the point of localizing all of %ENV. Why not just localize the
individual keys we want to fiddle with in the same scope as the
spawned command and let scope exit do the clean-up:
{
local $ENV{'foo'}='bar';
_runperl($cmd);
}
--
________________________________________
Craig A. Berry
mailto:[EMAIL PROTECTED]
"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser
