in reply to Re^15: Using STDIN after exec() with ActiveState Perl
in thread Using STDIN after exec() with ActiveState Perl

Here is the code for test.pl:
use warnings; use strict; use Module::Load; if(! $ENV{SPRING_WRITEDIR}) { $ENV{SPRING_WRITEDIR}='E:\\test'; exec {$^X} ($^X,$0); } $ENV{PATH}="E:\\springrts;$ENV{PATH}"; load("PerlUnitSync"); PerlUnitSync::Init(0,0); my $writeDir=PerlUnitSync::GetWritableDataDirectory(); print "writeDir=$writeDir\n";
Here is the output:
E:\test>perl test.pl E:\test>writeDir=E:\test\
And now the output if I comment the exec line:
E:\test>perl test.pl writeDir=D:\Documents\My Games\Spring\
As you can see the SPRING_WRITEDIR environment variable is not taken into account if I don't use exec.

Replies are listed 'Best First'.
Re^17: Using STDIN after exec() with ActiveState Perl
by RonW (Parson) on Jun 22, 2015 at 20:30 UTC

    Update: Ok, so can't use a BEGIN block...

    On Windows, exec is simulated in a strange way. Apparently, it's creating a new process and exiting the caller before the new process exits.

    (Update 2: On Linux, exec does not start a new process, it loads a new executable into the calling process. From the command shell's point of view, the process it launched is still running, so it's not trying to read STDIN.)

    Your problem with system is that you need to exit after system returns:

    use warnings; use strict; use Module::Load; if(! $ENV{SPRING_WRITEDIR}) { $ENV{SPRING_WRITEDIR}='E:\\test'; system {$^X} ($^X,$0); exit; }

    Yes, you will have 2 Perl processes where you had 1, but one of those will be idle while waiting on the other to exit.

    Please try:

    use warnings; use strict; BEGIN { $ENV{SPRING_WRITEDIR}='E:\\test'; $ENV{PATH}="E:\\springrts;$ENV{PATH}"; } use Module::Load; load("PerlUnitSync"); PerlUnitSync::Init(0,0); my $writeDir=PerlUnitSync::GetWritableDataDirectory(); print "writeDir=$writeDir\n";

    This will set the environment before Module::Load is loaded.

      Thanks for looking into this. The problem is that my script must be able to modify the environment variables as many times as needed during its execution, which would lead to a growing number of idle perl processes with this solution.

        Thanks for looking into this. The problem is that my script must be able to modify the environment variables as many times as needed during its execution, which would lead to a growing number of idle perl processes with this solution.

        I would argue you must be missing an API call that exists and does the same thing directly, no relying on %ENV

        Are there several processes running in parallel that use different version of the library?

        If they are not parallel, instead of exiting after system returns, loop back up and determine the next set of ENV variable settings for the next run via system.

        If several parallel sequential runs, just run as many "top level" instances of the top level Perl program as needed.

Re^17: Using STDIN after exec() with ActiveState Perl
by Anonymous Monk on Jun 21, 2015 at 22:10 UTC

        output of perl -V: http://pastebin.com/6bE8L9vA

        This is perlmonks, we don't need pastebins

        Anyway, 5.20.1 is plenty new

        Yeah, swig perl "%ENV" finds %ENV vs C's setenv which suggests Env::C - Get/Set/Unset Environment Variables on the C level

        "plain xs" works for gettin %ENV changes reflected ; I never cared much for swig

        #!/usr/bin/perl -- use strict; use Inline C => Config => BUILD_NOISY => 1; use Inline C => <<'END_C', NAME => 'modSV', CLEAN_AFTER_BUILD => 0; #include <stdlib.h> /* setenv/getenv */ char* modSV() { return getenv("HORSEY"); } END_C use Data::Dump qw/ dd /; dd( $ENV{HORSEY} => modSV() ); $ENV{HORSEY}='Neigh'; dd( $ENV{HORSEY} => modSV() ); __END__ (undef, undef) ("Neigh", "Neigh")