Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

setenv in perl

by dideod.yang (Acolyte)
on Jul 09, 2018 at 00:04 UTC ( #1218130=perlquestion: print w/replies, xml ) Need Help??
dideod.yang has asked for the wisdom of the Perl Monks concerning the following question:

I have a question about setenv in perl. I have to use setenv to operate some command... so I use %ENV. but it can not operate.. I use perl in linux. For more details, I type 'setenv test TURE' then when I type 'echo $test' linux print TURE. Also I can find 'test=TURE' when I type 'printenv' in linux. I want to use all of these command through perl script. How can I do it?? I test below some command but it didn't work.. Can you help me?? I want to set new envirmoent value in linux, when I type 'printenv'. thank you monks
$ENV{test} = "TRUE"; $command = `setenv test TRUE`; system "setenv test TRUE";

Replies are listed 'Best First'.
Re: setenv in perl
by Corion (Pope) on Jul 09, 2018 at 07:37 UTC

    The traditional approach to pass environment variables upwards is to output a shell script and source that shell script from the calling shell:

    eval "$("

    If you want to see and capture which shell variables a shell script sets up, a good approach is to run that shell script in a subshell and then output the resulting values. See for example Get default login environment and the comments to it, and also Shell::GetEnv.

Re: setenv in perl
by LanX (Bishop) on Jul 09, 2018 at 01:28 UTC
    I'm not sure if I understand you correctly, but if you are trying to set the environment of the parent process calling your Perl script, then that's not possible.

    The environment is always copied from parent to child process and not shared.

    A changed environment in your Perl script is only visible inside this script and children processes of that script.

    Cheers Rolf
    (addicted to the Perl Programming Language :)
    Wikisyntax for the Monastery FootballPerl is like chess, only without the dice


    If your problem is in the other direction, try export with variables meant to be available to a child process

    lanx@ubuntu:~$ export TEST=TRUE lanx@ubuntu:~$ perl -E 'say $ENV{TEST}' TRUE
      Can you qx/export .../?
        you can but it doesn't make sense, since %ENV is by definition automatically exported.

        lanx@ubuntu:~$ perl -E '$ENV{TEST}=TRUE; say `echo \$TEST` ' TRUE

        Again, you can only effect the child process.

        ( update: please note you have three different processes in this example: ~$ Bash > Perl -E '...' > `Bash` )

        If you want to effect the parent process, you need to return text information which is either eval'ed or source'd (when put into a file).

        lanx@ubuntu:~$ eval `perl -E 'say q{export TEST=TRUE}'` lanx@ubuntu:~$ echo $TEST TRUE

        In other words the parent process always keeps full control of the environment.

        Cheers Rolf
        (addicted to the Perl Programming Language :)
        Wikisyntax for the Monastery FootballPerl is like chess, only without the dice

Re: setenv in perl
by Tux (Abbot) on Jul 09, 2018 at 09:29 UTC

    When you use system or backticks or qx{}, the command is executed in a newly spawned shell, so setting an environment variable using one of these methods will not reflect to the calling process. Consider it to be equivalent to (I used $$ to show that it is the prompt of the sub-shell)

    $ export A=1 $ echo $A 1 $ bash $$ echo $A 1 $$ export A=2 $$ echo $A 2 $$ exit $ echo $A 1

    So, those three are out.

    The case of %ENV is way more interesting, as it involves scope and timing. Lets start with simple examples:

    $ echo $A;perl -wE'say $ENV{A};$ENV{A}=2;say$ENV{A}';echo $A 1 1 2 1 $ perl -wE'say $ENV{A};qx{echo \$A};$ENV{A}="B";say $ENV{A };qx{echo \$A};' 1 B

    You can observe that the proces spawned with the first qx uses the original value stored in $A, and the second invocation uses the changed value, as you expect (if I read your question correctly), so no surprises there.

    What will complicate matters is if those %ENV values are used in the startup phase of a module that you use. This implies that the value is used before you change its value. In that case, you should do something like

    BEGIN { $ENV{test} = "B"; } use My::Module; # Which initializes with $ENV{test}

    Now the environment is set before it is seen by the module.


    Enjoy, Have FUN! H.Merijn
Re: setenv in perl
by Anonymous Monk on Jul 09, 2018 at 07:40 UTC
Re: setenv in perl
by Dallaylaen (Hermit) on Jul 09, 2018 at 06:01 UTC

    It's not clear from the post what you are trying to achieve. Do you want to set variable test in the shell that is calling your perl script? Or do you want to set test in further processes created by your program via system?

      Yes I want to achieve set variable test in the shell through perl script. So If I source perl script and I type 'echo $text' in linux screen, then output will be 'TRUE'. Easily I want to use 'setenv' function in perl script.. but I don't know how to use 'setenv' in perl script... Thank you

        In the scary old times of DOS, it was possible to patch the environment of the parent process. But then again, you could even patch away DOS and replace it with something completely different.

        There is a theory which states that if ever anyone discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.

        There is another theory which states that this has already happened.

        -- Douglas Adams, The Restaurant at the End of the Universe

        DOS is single user, single task, without any memory protection.

        Unix is multi-user, multi-task, and usually has memory protection. And it is a good thing that you can not patch the environment of your parent process. It would be a security hole. Imagine this:

        1. root logs in
        2. root enters cd /tmp
        3. root enters sudo -u nobody /some/where/dangerous
        4. sudo switches the current user to nobody and drops privileges
        5. sudo replaces itself with /some/where/dangerous (simply using exec())
        6. /some/where/dangerous attempts to patch the environment of its parent process, i.e. root's login shell
        7. root enters ls

        On a system that allows patching the environment of the parent process, root would have lost control over the system. /some/where/dangerous has changed $ENV{'PATH'} of the login shell so that a directory containing malicious software under common names (ls, rm, vi, touch, ...) is searched first. That software runs with root privileges, i.e. no limits.

        On a system as we know it, /some/where/dangerous can't do that.

        Of course, working as root is a bad idea to start with, and relying on $ENV{'PATH'} as root is even worse. But such things happen.

        It does not have to be that bad, the same problem would happen even without sudo and for any user if software messes with the parent's environment.


        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)
YES you can! Re: setenv in perl
by bliako (Friar) on Jul 09, 2018 at 13:21 UTC

    Prepare to be enlightened:

    #!/usr/bin/perl # setenv from within perl to effect parent shell # actually parent should be more appropriately # called "adopted" or "step-parent", re execl # there is one little requirement: # you should run this program via shell's exec: # % exec <scriptname> # # author: bliako # date: 09/07/2018 use Inline C => DATA; # ... # this should be the last statement in your script # because nothing else will be executed after that # not even the 'or die ...' mysetenv("test", "TURE") or die "mysetenv() failed"; __END__ __C__ #include <stdio.h> #include <unistd.h> #include <stdlib.h> int mysetenv(const char *K, const char *V){ if( K==NULL || V==NULL ){ return 0; } char *shell = getenv("SHELL"); if( setenv(K, V, 1) ){ fprintf(stderr, "mysetenv() : call to setenv() has fai +led.\n"); return 1; } // replace caller shell with a new shell which now has // set this new env var //printf("shell to exec is %s\n", shell); execl(shell, NULL, NULL); perror("execl failed, "); return 1; }
    % echo $test
    % exec
    % echo $test

    The above script sets the specified environment variable and at the same time replaces current program (the perl script) with a new shell which inherits the env. If this script is executed via shell's exec, e.g. % exec the current shell will be replaced by the new shell created in the perl script and having the set environment.

    For more flexibility, the mysetenv() function should be split into 2 parts. The setenv part and the execl part. The execl part should be executed last. After execl call the perl script process stops to exist!

    bw, bliako (and excuse my boasting)

      Corion observed that this can be done using only pure Perl. Which is right but somehow escaped me. So here it is in pure Perl. You still need to execute the script via exec

      #!/usr/bin/perl # setenv from within perl to effect parent shell # actually parent should be more appropriately # called "adopted" or "step-parent", re execl # there is one little requirement: # you should run this program via shell's exec: # % exec <scriptname> # # this is pure-Perl implementation after Corion's # comment. # set env $ENV{test} = 'TURE'; # ... # this should be the last statement in your script # because nothing else will be executed after that # not even the 'or die ...' die "no shell!" unless defined($ENV{SHELL}); exec($ENV{SHELL}); __END__
      Yes exec doesn't spawn a child process but hands over control to another "executable" on the same level, which never returns.

      Your trick only works interactively because you need to exec a NEW follow up shell, waiting for human input.

      This means this illusion won't work in a non interactive script. All code after the exec will be ignored.

        On a more serious node, the exec() is a safe (Edit: not safe as in safety and security) way to achieve what the question asked as my use-case demonstrated. It is true that unless one executes the "trick" from an interactive shell any command past that exec will not run as KurtZ whines rightly points out. For example as a cron job.

        I don't see it as a "trick" because this is what exec() was intended to do in the first place. It is not exploiting any of its features=bugs, it is not using it in a heads-down-feet-up kind of way.

        And definetely the result is not an illusion because it's there. You get your environment modified albeit within a brand new shell which inherits from the parent shell. It inherits env variables and even opened file descriptors. For example:

        exec 3> /tmp/out echo 'before exec' >&3 exec echo 'after exec' >&3 exec 3>&- cat /tmp/out before exec after exec

        So, not a trick, not an illusion but limited (and what isn't) to interactive shells.

        For non-interactive use, e.g. a cron-job one can go with Corion's Re: setenv in perl. And if only 1 env-variable needs to be set up, then the eval can be avoided by using:

        export test=`perl -e 'print 'TURE'`

        Lastly, if the scenario is to run a shell command which reads data from the environment and having a perl script to calculate this data and export it to the environment then why not let perl calculate AND spawn the command because any system() call inherits perl's environment vars, like so:

        #!/usr/bin/env perl $ENV{test} = 'TURE'; # calculate my @cmd = ('command-exec', 'args'); system(@cmd); # spawn # simple demo: system('echo $test'); # prints what

        bw, bliako

        Nope! Not in a Quantum Computer running UNIX. There, in a parallel universe my "trick"'s "illusion" will warp into reality.

      Clever. Here's what happens.

      When you run Perl with exec, it replaces the shell in the same process. This is the key; just running Perl as it is usually done will not have this effect, which is why you got so many "It can't be done" responses. Because environment variables live in a process, the Perl script sees the same environment the shell did.

      When you then exec the shell after modifying the environment, the new copy of the shell, still running in the same process, sees those modifications.

      I do have a couple observations to add.

      This approach only works if you have control over how your Perl script is run.

      Unless the Perl script is in the PATH, I found I needed to explicitly specify the directory: ./

      If you do it this way, you do not need to use Inline::C. Simply modifying %ENV will work:

      #!/usr/bin/env perl use 5.008; use strict; use warnings; $ENV{test} = 'TURE'; exec $ENV{SHELL} or die "Failed to exec shell '$ENV{SHELL}'\n";

      works just as well:

      $ echo "PID=$$; test='$test'" PID=87533; test='' $ exec ./ $ echo "PID=$$; test='$test'" PID=87533; test='TURE'

      I was trying to follow your post as I think triangulating this question with C makes complete sense. Have I missed a step?

      $ touch $ chmod +x $ gedit &

      I paste in your code and set it to execute. First I need

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1218130]
Approved by marto
Front-paged by haukex
[Happy-the-monk]: Moin !

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (4)
As of 2018-07-23 08:06 GMT
Find Nodes?
    Voting Booth?
    It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?

    Results (459 votes). Check out past polls.