From @smpeters

This problem originally occured while running tests for installing
Test​::Harness, but I've been able to replicate it independently. For
reference, the original ticket is available at
http​://rt.cpan.org/NoAuth/Bug.html?id=6452.

The problem is that an local environment variable set in an anonymous block
seems to be available to child processes created afterwards using qx(). I
have not tested this using system() or fork(). See the example scripts
below.

test1.pl

#!/usr/bin/perl -w

use warnings;
use strict;

my $key = "WANGO";

BLOCK1​: {
  my $val = $ENV{$key};
  $val = "undef" unless defined $val;
  print "In BLOCK1, \$ENV{$key} = [$val]\n";
}

BLOCK2​: {
  local $ENV{$key} = "FOTANGO";

  my $val = $ENV{$key};
  $val = "undef" unless defined $val;
  print "In BLOCK2, \$ENV{$key} = [$val]\n";
}

BLOCK3​: {
  my $val = qx/test2.pl/;
  $val = "undef" unless defined $val;
  print "In BLOCK3, \$ENV{$key} = [$val]\n";
  print " ... BUT IT SHOULD BE undef!" unless $val eq "undef";
}

=cut

test2.pl

#!/usr/bin/perl -w

use strict;
my $val = $ENV{WANGO};
$val = "undef" if ! defined $val;
print $val;

=cut

My results on Cygwin are...

In BLOCK1, $ENV{WANGO} = [undef]
In BLOCK2, $ENV{WANGO} = [FOTANGO]
In BLOCK3, $ENV{WANGO} = [FOTANGO]
  ... BUT IT SHOULD BE undef!

On Linux (Perl 5.8.4 on Gentoo with a 2.4.26 kernel), Win32 (ActiveState Build
810), HP-UX (Perl 5.8.0), and Mac OS X (Perl 5.8.0), the results are...
In BLOCK1, $ENV{WANGO} = [undef]
In BLOCK2, $ENV{WANGO} = [FOTANGO]
In BLOCK3, $ENV{WANGO} = [undef]

Adding an "$ENV{WANGO} = undef;" to the end of BLOCK2 seems to take care of
the problem, but coding this way for just one platform doesn't seem quite
right to me. I'm also not sure if this is actually a problem with Perl or an
issue with Cygwin itself.

Regards,

Steve Peters
steve@​fisharerojo.org

From @petdance

This problem is causing problems with t/prove-switches.t in Test​::Harness.

From fluffy@sixears.co.uk

On Thu, Aug 05, 2004 at 03​:26​:34AM -0000, Steve Peters wrote​:

The problem is that an local environment variable set in an anonymous block
seems to be available to child processes created afterwards using qx(). I
have not tested this using system() or fork(). See the example scripts
below.

I tried the supplied scripts, but didn't get the results you describe.
I get​:
[martyn​:0]$ PATH=$PATH​:/tmp /tmp/test1.pl
In BLOCK1, $ENV{WANGO} = [undef]
In BLOCK2, $ENV{WANGO} = [FOTANGO]
In BLOCK3, $ENV{WANGO} = [undef]

Please retry them in a separate session; I have to imagine that you have
"WANGO" set in your environment, or similar.

Mx.

The RT System itself - Status changed from 'new' to 'open'

From @smpeters

I tried the supplied scripts, but didn't get the results you describe.
I get​:
[martyn​:0]$ PATH=$PATH​:/tmp /tmp/test1.pl
In BLOCK1, $ENV{WANGO} = [undef]
In BLOCK2, $ENV{WANGO} = [FOTANGO]
In BLOCK3, $ENV{WANGO} = [undef]

Please retry them in a separate session; I have to imagine that you have
"WANGO" set in your environment, or similar.

As far as I know, I don't have an environment variable called "WANGO" in my
environment. My guess is that this may be related to the Windows version I
have. The machine that this failed on has NT 4.0 installed. Let me try it
on my XP box and see if I get the same error.

Steve Peters
steve@​fisharerojo.org

From @smpeters

As far as I know, I don't have an environment variable called "WANGO" in my
environment. My guess is that this may be related to the Windows version I
have. The machine that this failed on has NT 4.0 installed. Let me try it
on my XP box and see if I get the same error.

OK, I tried it on my Windows XP box and it worked just fine. It must be the
combination of Windows NT 4.0 and Cygwin that's causing these problems.

Steve Peters
steve@​fisharerojo.org

From guest@guest.guest.xxxxxxxx

Bug still present on perl 5.8.7 cygwin-thread-multi-64int / nt4

$ perl test.pl
In BLOCK1, $ENV{WANGO} = [undef]
In BLOCK2, $ENV{WANGO} = [FOTANGO]
In BLOCK3, $ENV{WANGO} = [FOTANGO]
... BUT IT SHOULD BE undef!
$ uname -a
CYGWIN_NT-5.0 reini 1.5.19s(0.137/4/2) 20050814 16​:02​:26 i686 unknown
unknown Cygwin

I'll report at the cygwin list

From @smpeters

[guest - Wed Sep 28 23​:42​:02 2005]​:

Bug still present on perl 5.8.7 cygwin-thread-multi-64int / nt4

$ perl test.pl
In BLOCK1, $ENV{WANGO} = [undef]
In BLOCK2, $ENV{WANGO} = [FOTANGO]
In BLOCK3, $ENV{WANGO} = [FOTANGO]
... BUT IT SHOULD BE undef!
$ uname -a
CYGWIN_NT-5.0 reini 1.5.19s(0.137/4/2) 20050814 16​:02​:26 i686 unknown
unknown Cygwin

I'll report at the cygwin list

The problem was with Perl's handling of environment variables when Perl
is compiled with -DPERL_USE_SAFE_PUTENV. This has been fixed with
change #25737.

steve@​redshirt ~/perl-current
$ perl5.8.7.exe test1.pl
In BLOCK1, $ENV{WANGO} = [undef]
In BLOCK2, $ENV{WANGO} = [FOTANGO]
In BLOCK3, $ENV{WANGO} = [FOTANGO]
  ... BUT IT SHOULD BE undef!
steve@​redshirt ~/perl-current
$ ./perl test1.pl
In BLOCK1, $ENV{WANGO} = [undef]
In BLOCK2, $ENV{WANGO} = [FOTANGO]
In BLOCK3, $ENV{WANGO} = [undef]

@smpeters - Status changed from 'open' to 'resolved'