Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

qx// and run() do not respect %*ENV change in rakudo-parrot #3276

Closed
p6rt opened this issue Nov 13, 2013 · 11 comments
Closed

qx// and run() do not respect %*ENV change in rakudo-parrot #3276

p6rt opened this issue Nov 13, 2013 · 11 comments

Comments

@p6rt
Copy link

p6rt commented Nov 13, 2013

Migrated from rt.perl.org#120529 (status was 'rejected')

Searchable as RT120529$

@p6rt
Copy link
Author

p6rt commented Nov 13, 2013

From dram.wang@gmail.com

In rakudo-parrot 2013.10, both qx// and run() do not respect %*ENV change.

shell() has no problem, also there is no problem in rakudo-jvm.

%*ENV{'ENV_TEST'} = 'foo'; say qx/env/ ~~ /ENV_TEST/;
Nil
%*ENV{'ENV_TEST'} = 'foo'; shell 'env | grep ENV_TEST';
ENV_TEST=foo

@p6rt
Copy link
Author

p6rt commented Nov 13, 2013

From @FROGGS

Hi, shell() is supposed to spawn a shell as the name suggests (`sh` on linuxes, `cmd.exe` on windows).
run() and qx// do *not* spawn a shell. So you must be a bit carefull when acessing enironment vars.

Examples​:
perl6-p -e '%*ENV<ENV_TEST>="foo"; run("sh", "-c", "echo \$ENV_TEST")'
foo

perl6-p -e '%*ENV<ENV_TEST>="foo"; run("env")'
LIBOVERLAY_SCROLLBAR=0
[...]
ENV_TEST=foo

This however seems to be a valid bug​:
perl6-p -e '%*ENV<ENV_TEST>="foo"; say qx/env/ ~~ /ENV_TEST/'
Nil

@p6rt
Copy link
Author

p6rt commented Nov 13, 2013

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

@p6rt
Copy link
Author

p6rt commented Nov 15, 2013

From dram.wang@gmail.com

On Wed Nov 13 09​:53​:15 2013, FROGGS.de wrote​:

Hi, shell() is supposed to spawn a shell as the name suggests (`sh` on
linuxes, `cmd.exe` on windows).
run() and qx// do *not* spawn a shell. So you must be a bit carefull
when acessing enironment vars.

Yes, I'm aware of that, but I think in both case (spawn and non-spawn), environment vars need to be passed into subprocesses.

Examples​:
perl6-p -e '%*ENV<ENV_TEST>="foo"; run("sh", "-c", "echo \$ENV_TEST")'
foo

perl6-p -e '%*ENV<ENV_TEST>="foo"; run("env")'
LIBOVERLAY_SCROLLBAR=0
[...]
ENV_TEST=foo

Curious that my results are different when running those two lines​:

$ perl6 -e '%*ENV<ENV_TEST>="foo"; run("sh", "-c", "echo \$ENV_TEST")'

$ perl6 -e '%*ENV<ENV_TEST>="foo"; run("env")' | grep ENV_TEST
$

I tested them in bash and mksh under linux, not sure if it is relevant.

This however seems to be a valid bug​:
perl6-p -e '%*ENV<ENV_TEST>="foo"; say qx/env/ ~~ /ENV_TEST/'
Nil

@p6rt
Copy link
Author

p6rt commented Nov 15, 2013

From dram.wang@gmail.com

2013/11/14 Tobias Leich via RT <perl6-bugs-followup@​perl.org>

Hi, shell() is supposed to spawn a shell as the name suggests (`sh` on
linuxes, `cmd.exe` on windows).
run() and qx// do *not* spawn a shell. So you must be a bit carefull when
acessing enironment vars.

Yes, I'm aware of that, but I think in both case (spawn and non-spawn),
environment vars need to be passed into subprocesses.

Examples​:
perl6-p -e '%*ENV<ENV_TEST>="foo"; run("sh", "-c", "echo \$ENV_TEST")'
foo

perl6-p -e '%*ENV<ENV_TEST>="foo"; run("env")'
LIBOVERLAY_SCROLLBAR=0
[...]
ENV_TEST=foo

Curious that my results are different when running those two lines​:

$ perl6 -e '%*ENV<ENV_TEST>="foo"; run("sh", "-c", "echo \$ENV_TEST")'

$ perl6 -e '%*ENV<ENV_TEST>="foo"; run("env")' | grep ENV_TEST
$

I tested them in bash and mksh under linux, not sure if it is relevant.

This however seems to be a valid bug​:
perl6-p -e '%*ENV<ENV_TEST>="foo"; say qx/env/ ~~ /ENV_TEST/'
Nil

@p6rt
Copy link
Author

p6rt commented Nov 15, 2013

From @FROGGS

You would need a rakudo that is not more than two weeks old I think.
run() was fixed just a few weeks ago.

And yes, all variants should pass the environment vars along, I just wanted to mention that you need to be careful when using shell patterns. Since `echo $ENV_TEST` will only work using a shell, ever.

Fixing qx// means fixing sub QX, which opens a pipe and captures STDOUT that way...
I need to find time to look into that.

@p6rt
Copy link
Author

p6rt commented Nov 16, 2013

From dram.wang@gmail.com

On Fri Nov 15 06​:52​:58 2013, FROGGS.de wrote​:

You would need a rakudo that is not more than two weeks old I think.
run() was fixed just a few weeks ago.

Works on master branch, great!

And yes, all variants should pass the environment vars along, I just
wanted to mention that you need to be careful when using shell
patterns. Since `echo $ENV_TEST` will only work using a shell, ever.

Get it. :)

Fixing qx// means fixing sub QX, which opens a pipe and captures
STDOUT that way...
I need to find time to look into that.

Ok, no hurry.

@p6rt
Copy link
Author

p6rt commented Oct 17, 2014

From @usev6

This works fine with Moar and JVM, but is still an issue with Parrot​:

$ perl6-m -e '%*ENV<ENV_TEST>="foo"; say qx/env/ ~~ /ENV_TEST/' ## same result with perl6-j
「ENV_TEST」

$ perl6-p -e '%*ENV<ENV_TEST>="foo"; say qx/env/ ~~ /ENV_TEST/'
Nil

I added a test (fudged 'todo' for Parrot) to S02-literals/quoting.t with the following commit​: Raku/roast@a3b0edce25

1 similar comment
@p6rt
Copy link
Author

p6rt commented Oct 17, 2014

From @usev6

This works fine with Moar and JVM, but is still an issue with Parrot​:

$ perl6-m -e '%*ENV<ENV_TEST>="foo"; say qx/env/ ~~ /ENV_TEST/' ## same result with perl6-j
「ENV_TEST」

$ perl6-p -e '%*ENV<ENV_TEST>="foo"; say qx/env/ ~~ /ENV_TEST/'
Nil

I added a test (fudged 'todo' for Parrot) to S02-literals/quoting.t with the following commit​: Raku/roast@a3b0edce25

@p6rt
Copy link
Author

p6rt commented Feb 27, 2015

From @usev6

Since support for Parrot was suspended with Rakudo Star Release 2015.02, I'm closing this "parrot only" ticket.

I added the ticket to a list of closed ticket living in the Mu repository​: https://github.com/perl6/mu/blob/master/misc/rt.perl.org/tickets_closed_parrot_only.txt.

In case support for Parrot will be restored in some future release the listed tickets can be checked and re-opened as appropriate.

@p6rt p6rt closed this as completed Feb 27, 2015
@p6rt
Copy link
Author

p6rt commented Feb 27, 2015

@usev6 - Status changed from 'open' to 'rejected'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant