On Fri, Feb 22, 2008 at 12:09 PM, Craig A. Berry <[EMAIL PROTECTED]> wrote:
> 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.
For my part, I did it for "maximum freshness"
IOW, no well-grounded reason vs your approach.
> 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:
Ive altered the patch to do that / this:
local $ENV{$_} = $args{env}$_} foreach $args{env}{$_};
This works too, so if its better for you, thats great.
diff.tenv2
Description: Binary data
