Re^2: Problem running IPTraf from Perl

The idea of not changing global variables is a good thought, but, changing $ENV within a perl script does not effect the shell that the script was run from, you can see that by doing:

$ echo $TERM; perl -e '$ENV{$TERM} = "strange";'; echo $TERM
[download]

This holds true whether you edit the (any) variable from Perl or from another (sub-)shell.

Comment on Re^2: Problem running IPTraf from Perl Download Code

Replies are listed 'Best First'.
Re^3: Problem running IPTraf from Perl by rblasch (Monk) on Jun 17, 2006 at 12:55 UTC
True, the environment only propagates down the process tree. But any process spawned by the script will see the changed environment, and these changes might be unexpected by other parts of the program. TERM might not be a problem, but others like PATH, LD_PRELOAD, or something else might well be. I like to make global changes, not only the environment but every global perl variable, as `local` as possible. print `echo %TERM%`; $ENV{TERM} = 'vt220'; # In some code, far, far away... print `echo %TERM%`; [download] `C:\tmp>perl t.pl %TERM% vt220` [download]	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Problem running IPTraf from Perl
by rblasch (Monk) on Jun 17, 2006 at 12:55 UTC

True, the environment only propagates down the process tree. But any process spawned by the script will see the changed environment, and these changes might be unexpected by other parts of the program. TERM might not be a problem, but others like PATH, LD_PRELOAD, or something else might well be.

I like to make global changes, not only the environment but every global perl variable, as local as possible.

print `echo %TERM%`;
$ENV{TERM} = 'vt220';

# In some code, far, far away...
print `echo %TERM%`;
[download]

C:\tmp>perl t.pl
%TERM%
vt220
[download]

[reply]
[d/l]
[select]