Kernel.system leaks ENV on JRuby + Windows

[deivid-rodriguez]

Take the following script:

puts ENV["FOO"]

system({"FOO" => "true"}, "true")

puts ENV["FOO"]

On my Linux box it prints two blank lines on both CRuby and JRuby. However on Windows in prints two blank lines with CRuby, but a blank line followed by "true" on JRuby.

Expected Behavior

Two blank lines printed.

Actual Behavior

Second line prints "true" meaning that the FOO variable passed to the subprocess has leaked into the main process.

I see some process launching fixes on Windows scheduled for 9.2.18.0, so not sure if this might have already been fixed. If so, please close this and looking forward to the release :)

[headius]

How peculiar! This is not fixed by my open3 fixes, even though there was some env juggling in that PR.

>bin\jruby -v -e "p ENV['FOO']; system({'FOO' => 'BAR'}, 'echo %FOO%'); p ENV['FOO']"
jruby 9.2.18.0-SNAPSHOT (2.5.8) 2021-04-09 9ec662d9b1 OpenJDK 64-Bit Server VM 11.0.10+9 on 11.0.10+9 +jit [mswin32-x86_64]
nil
BAR
"BAR"

Should be easy to fix.

[headius]

Reproducible on unix with -Xnative.enabled=false.

[headius]

Ah so the logic I fixed is good (the path RubyIO.popen3 calls, via ShellLauncher.popen3, now peels the env off before launching) but the Kernel.system path just does a blind merge of the requested env with the current one. Just need to remove that logic now.

[headius]

Will be fixed by #6655:

C:\jruby>bin\jruby -v -e "p ENV['FOO']; system({'FOO' => 'BAR'}, 'echo %FOO%'); p ENV['FOO']"
jruby 9.2.18.0-SNAPSHOT (2.5.8) 2021-04-09 a0e8f28ad9 OpenJDK 64-Bit Server VM 11.0.10+9 on 11.0.10+9 +jit [mswin32-x86_64]
nil
BAR
nil

[headius]

FYI this was not a regression... the env merge code appears to exist as far back as 1.7.0: 24031a9

It probably was not noticed before now because there are fewer users on Windows (and you would have to look for this to see it happening).

[headius]

Thanks for the report, @deivid-rodriguez! You are the first one to notice this in almost ten years!

[deivid-rodriguez]

Thanks for the quick fix @headius!