Environment variables are not always propagated to sub-process #15529
Comments
From cherio@gmail.comCreated by cherio@gmail.comEnvironment variables with '.' (dot character) are not always passed to the $ENV{'test.variable'} = 'Hello kitty'; However a slightly modified version of the same code works and $ENV{'test.variable'} = 'Hello kitty'; This is a regression. It worked both ways in Perl 5.18 Perl Info |
From cherio@gmail.comEnvironment variables with '.' (dot character) are not always passed to the $ENV{'test.variable'} = 'Hello kitty'; However a slightly modified version of the same code works and $ENV{'test.variable'} = 'Hello kitty'; This is a regression. It worked both ways in Perl 5.18 |
From cherio@gmail.comCreated by cherio@gmail.comEnvironment variables with '.' (dot character) are not always passed to the child process. $ENV{'test.variable'} = 'Hello kitty'; However a slightly modified version of the same code works and 'test.variable' is available in the child program $ENV{'test.variable'} = 'Hello kitty'; This is a regression. It worked both ways in Perl 5.18 Perl Info |
From @dcollinsnMerging accidental duplicates. -- |
From zefram@fysh.orgCherio wrote:
It works for me, both ways, on 5.22, 5.18, and other Perl versions. The way that you're saying doesn't work involves perl invoking a shell Try running the Perl program under "strace -fveexecve". That will -zefram |
|
The RT System itself - Status changed from 'new' to 'open' |
From @iabynOn Fri, Aug 19, 2016 at 11:14:03AM -0700, Cherio wrote:
I can't reproduce this, not on 5.22.1 nor bleadperl. I think this is an issue with your shell rather than perl. I'd suggest running an strace to see which program is dropping the Here I run it against a couple of small demo scripts. $ cat /tmp/demo $ cat /tmp/show_env $ perl5221 /tmp/demo $ strace -f -e trace=execve -v perl5221 /tmp/demo Here we see perl5221 being run, which calls /bin/sh, passing it $test.variable, What do you get when you run strace as above against those two scripts? -- |
From dennis@kaarsemaker.netOn za, 2016-08-20 at 09:15 +0100, Dave Mitchell wrote:
As usual dash is being strict hurricane:~$ env FOO=1 dash -c 'env | grep FOO' |
From cherio@gmail.comI got an exact working example, just copy & paste into your terminal and you'll reproduce it cat > ./show-env.pl <<EOF Seems like single quotes inside a double quoted string make the difference |
From cherio@gmail.comOn Sat Aug 20 22:56:53 2016, cherio@gmail.com wrote:
The regression can be reproduced in Ubuntu 16.04, it doesn't occur in Ubuntu 14.04. |
From @iabynSince its been shown that this is related to a particular shell's handling of environment variables and not related to perl, I'm marking the ticket rejected |
|
@iabyn - Status changed from 'open' to 'rejected' |
From @iabynOn Fri, Aug 19, 2016 at 11:03:30AM -0700, Cherio wrote:
Any environment variable removal is been done by your shell, not perl. Closing. -- |
From @iabynOn Thu, Mar 30, 2017 at 11:29:09AM +0100, Dave Mitchell wrote:
(And I didn't spot that this ticket was a duplicate that had already -- |
Migrated from rt.perl.org#128995 (status was 'rejected')
Searchable as RT128995$
The text was updated successfully, but these errors were encountered: