Re^3: passing env{} variable to child fails on linux,works on windows

[dave_the_m]

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

Flexvault is mistaken. It's a child, and it does inherit environment variables. Here are a couple of linux scripts that demonstrate this. First, /tmp/myenv just prints any environment variables that have 'MY' in the name:

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

Then the main script, which 'opens' myenv:

#!/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";
}

Running this gives:

got: <MYA=>a>
got: <MYB=>b>

Dave.

[sdetweil]

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);



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



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

[andal]

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
+.

[thargas]

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.