The simple answer is 'No'. Child processes get a copy of the parent's environment, see this

Apparently it is vaguely possible on MSWin32 with some craftiness

You can do this with a little cooperation between different processes. Consider the following:

#! /bin/sh
perl prog1 -x ./env.sh foo bar
[ -f ./env.sh ] && ./env.sh
perl prog2 quux
[download]

The idea is that prog1 writes valid shell commands to the env.sh file, does whatever else it has to do and then exits. Execution flow returns to the outer shell, which then sources the file that it wrote.

The prog2 program then runs, and picks up what ever environment changes were made by env.sh.

This is rather fragile and insecure. If you are brave and insist on this approach you really should consider using IPC (Inter-Process Communication) for a more robust solution. The idea is to create a channel of communication (child writes, parent reads) between the two. See perlipc for more information.

grinder++ I agree with you, that parents cooperating with children can cause a change in the parents environment. Hey, that probably holds true in real life as well...

My contribution here is that I implemented something similar, using unix signals. The parent would trap on an unused signal (I used SIGUSR1) and read-in-and-execute all the commands contained in a pre-defined temporary file.

When the child wanted to change something in the parents environment, it would write those changes to the pre-defined temporary file, then would poke-the-parent-in-the-side by sending a signal via the unix kill(1) command.

This worked well for me.

-Craig

my $status = system('(shs01.sh;thing.pl)');
[download]

i know that through child process I cant modify parents' variables. But just asking if there is a way

Fortunately not. I would feel very uneasy as a programmer if I had to worry whether my child processes secretly change my environment without me noticing. This is already pretty nasty in Windoze batch programming where this "feature" is possible.

IMHO, values should passed back to the parent in a way which is clearly visible (i.e. the caller has to ask for the values). How this is done, depends on the application being called. For instance, you might pass a filename to the application, and it writes any output parameters into the file. Or, the application uses stdout to pass data back, and you use qx() instead of system() to catch it.

This is already pretty nasty in Windoze batch programming where this "feature" is possible.

It is?

> type foo.cmd
perl -le "print q{FOOBAR=}, $ENV{FOOBAR}"
perl -e "$ENV{FOOBAR}=rand(9999)"
perl -le "print q{FOOBAR=}, $ENV{FOOBAR}"
[download]

This produces

FOOBAR=
FOOBAR=
[download]

Which seems to show that things are working as expected. Either that, or I suck at writing Windows batch files.

• another intruder with the mooring in the heart of the Perl

Windows batch processing.

@REM --------------------------------
@REM runme.cmd
@echo off
SET FOO=bar
echo %FOO%
echo Calling setter.cmd
call setter.cmd
echo After setter.cmd
echo %FOO%
[download]

@REM ---------------------------------
@REM setter.cmd
echo "I am in setter."
set FOO=biz
echo Setters FOO = %FOO%
[download]

--------------------------------------
output
--------------------------------------
bar
Calling setter.cmd
"I am in setter."
Setters FOO = biz
After setter.cmd
biz
[download]

The called sub command, setter.cmd, resets the environment of the caller.

--MidLifeXis