well, there it is then.. its not a 'child' its a peer..

#!/usr/bin/perl
print "$_=>$ENV{$_}\n" for grep /MY/, sort keys %ENV;
[download]

#!/usr/bin/perl

$ENV{MYA} = 'a';
$ENV{MYB} = 'b';
$ENV{C}   = 'c';
open(CMD, "/tmp/myenv 2>&1 |") or die "open: $!\n";
while (<CMD>) {
    chomp;
    print "got: <$_>\n";
}
[download]

got: <MYA=>a>
got: <MYB=>b>
[download]

Dave.

thank you.

using your example I tested on my platform, and it worked.

but my app didn't..

the difference was that I called $ENV{} from the thread code (&routine below), vs the main app code..



  threads->create(&routine);
[download]



moving the $ENV{} to the main code allows it to work.



  $ENV{'SKIP_SYSTEM'}='1';
  threads->create(&routine);
[download]

Here's the quote from perdloc threads

Currently, on all platforms except MSWin32, all system calls (e.g., us
+ing system() or back-ticks) made from threads use the environment var
+iable settings from the main thread. In other words, changes made to 
+%ENV in a thread will not be visible in system calls made by that thr
+ead.

To work around this, set environment variables as part of the system c
+all. For example:

    my $msg = 'hello';
    system("FOO=$msg; echo \$FOO"); # Outputs 'hello' to STDOUT

On MSWin32, each thread maintains its own set of environment variables
+.
[download]

One problem with your question is that you're using the word "child". For most unix folks, child implies that you're using fork, which you're not. Fork and threads work differently. The problem could have been avoided by providing a complete script.

sdetweil,

How about:

    my @results = qx/script.plx -$envparm/;
[download]

You get the results of the script in '@results' and you pass your script the required parameter that it needs.

Maybe?

Regards...Ed