How can I make environment variables “exported” in a shell script stick around?












45















I have multiple Amazon EC2 accounts and want to quickly be able to switch variables, such as $EC2_HOME, using a script.



I have have a shell script set up like this:



#!/bin/sh
export EC2_HOME=/home/me/.ec2
echo $EC2_HOME


When I run the script I know that EC2_HOME is set, but I thought that using export would make the variable stick around after the script completed. It does not, as running echo $EC_HOME does not show anything.



I know this must be very rudimentary Linux scripting knowledge, but I don't know it. I tried looking for related questions without luck - so my apologies if this is a duplicate.










share|improve this question





























    45















    I have multiple Amazon EC2 accounts and want to quickly be able to switch variables, such as $EC2_HOME, using a script.



    I have have a shell script set up like this:



    #!/bin/sh
    export EC2_HOME=/home/me/.ec2
    echo $EC2_HOME


    When I run the script I know that EC2_HOME is set, but I thought that using export would make the variable stick around after the script completed. It does not, as running echo $EC_HOME does not show anything.



    I know this must be very rudimentary Linux scripting knowledge, but I don't know it. I tried looking for related questions without luck - so my apologies if this is a duplicate.










    share|improve this question



























      45












      45








      45


      18






      I have multiple Amazon EC2 accounts and want to quickly be able to switch variables, such as $EC2_HOME, using a script.



      I have have a shell script set up like this:



      #!/bin/sh
      export EC2_HOME=/home/me/.ec2
      echo $EC2_HOME


      When I run the script I know that EC2_HOME is set, but I thought that using export would make the variable stick around after the script completed. It does not, as running echo $EC_HOME does not show anything.



      I know this must be very rudimentary Linux scripting knowledge, but I don't know it. I tried looking for related questions without luck - so my apologies if this is a duplicate.










      share|improve this question
















      I have multiple Amazon EC2 accounts and want to quickly be able to switch variables, such as $EC2_HOME, using a script.



      I have have a shell script set up like this:



      #!/bin/sh
      export EC2_HOME=/home/me/.ec2
      echo $EC2_HOME


      When I run the script I know that EC2_HOME is set, but I thought that using export would make the variable stick around after the script completed. It does not, as running echo $EC_HOME does not show anything.



      I know this must be very rudimentary Linux scripting knowledge, but I don't know it. I tried looking for related questions without luck - so my apologies if this is a duplicate.







      bash shell-script shell environment-variables






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Nov 27 '16 at 20:32









      Michael Homer

      47.4k8124162




      47.4k8124162










      asked Jan 27 '12 at 19:32









      cwdcwd

      13.7k52115157




      13.7k52115157






















          2 Answers
          2






          active

          oldest

          votes


















          51














          You should source your script, with



          . ./script


          or



          source ./script





          share|improve this answer



















          • 19





            the reason is that your script spawns a new shell process as a child of the current shell. Any environment changes you make in the child process cannot affect the parent. When you use . or source, you are not spawning a new child process, you are running the commands in the current shell.

            – glenn jackman
            Jan 27 '12 at 20:32






          • 1





            @glennjackman I have a similar problem and I have tried your solution but it logs me off from shell when I do . or source. Why is this happening ?

            – Patryk
            Feb 21 '12 at 13:03






          • 7





            @Patryk: maybe your script has an exit statement, so it is not suitable to be sourced.

            – enzotib
            Feb 21 '12 at 13:24











          • While source ./script works completely fine, sudo source ./script.sh says sudo: source: command not found. How can I do this using sudo?

            – 71GA
            Sep 27 '14 at 13:37






          • 1





            @71GA: depending on compilation preferences for sudo and depending on configuration settings in /etc/sudoers you can or cannot preserve your environment when running commands with sudo. I suggest you to try to source your script, and then run sudo with -E option to preserve the environment. If it does not work, I suppose there is very little you can do.

            – enzotib
            Sep 27 '14 at 13:52



















          34














          When you run a script it gets its own shell and its own environment, which disappear again as soon as the script is finished. To keep the environment variables around, source the script into your current shell:



          $ source ./a.sh


          or equivalently (but a little more portably) use the POSIX dot command:



          $ . ./a.sh


          Then the definitions will be put into your current shell's environment and be inherited by any programs you launch from it.



          To be closer to running a script, . a.sh will find a.sh by searching the directories in the PATH environment variable.





          There are some subtleties in how these behave, and whether . and source are the same (or present at all). . ./a.sh will definitely behave the same in every POSIX-compatible shell, but source and ., and . a.sh and . ./a.sh, can vary. For Bash source and . are the same in all cases; for zsh source always checks the current directory first; ksh is essentially similar.



          If the script name is given as a path (containing a /), that path is used directly in all cases. The most portably reliable thing to do is . ./script or . /path/to/script.






          share|improve this answer

























            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "106"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f30189%2fhow-can-i-make-environment-variables-exported-in-a-shell-script-stick-around%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            2 Answers
            2






            active

            oldest

            votes








            2 Answers
            2






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            51














            You should source your script, with



            . ./script


            or



            source ./script





            share|improve this answer



















            • 19





              the reason is that your script spawns a new shell process as a child of the current shell. Any environment changes you make in the child process cannot affect the parent. When you use . or source, you are not spawning a new child process, you are running the commands in the current shell.

              – glenn jackman
              Jan 27 '12 at 20:32






            • 1





              @glennjackman I have a similar problem and I have tried your solution but it logs me off from shell when I do . or source. Why is this happening ?

              – Patryk
              Feb 21 '12 at 13:03






            • 7





              @Patryk: maybe your script has an exit statement, so it is not suitable to be sourced.

              – enzotib
              Feb 21 '12 at 13:24











            • While source ./script works completely fine, sudo source ./script.sh says sudo: source: command not found. How can I do this using sudo?

              – 71GA
              Sep 27 '14 at 13:37






            • 1





              @71GA: depending on compilation preferences for sudo and depending on configuration settings in /etc/sudoers you can or cannot preserve your environment when running commands with sudo. I suggest you to try to source your script, and then run sudo with -E option to preserve the environment. If it does not work, I suppose there is very little you can do.

              – enzotib
              Sep 27 '14 at 13:52
















            51














            You should source your script, with



            . ./script


            or



            source ./script





            share|improve this answer



















            • 19





              the reason is that your script spawns a new shell process as a child of the current shell. Any environment changes you make in the child process cannot affect the parent. When you use . or source, you are not spawning a new child process, you are running the commands in the current shell.

              – glenn jackman
              Jan 27 '12 at 20:32






            • 1





              @glennjackman I have a similar problem and I have tried your solution but it logs me off from shell when I do . or source. Why is this happening ?

              – Patryk
              Feb 21 '12 at 13:03






            • 7





              @Patryk: maybe your script has an exit statement, so it is not suitable to be sourced.

              – enzotib
              Feb 21 '12 at 13:24











            • While source ./script works completely fine, sudo source ./script.sh says sudo: source: command not found. How can I do this using sudo?

              – 71GA
              Sep 27 '14 at 13:37






            • 1





              @71GA: depending on compilation preferences for sudo and depending on configuration settings in /etc/sudoers you can or cannot preserve your environment when running commands with sudo. I suggest you to try to source your script, and then run sudo with -E option to preserve the environment. If it does not work, I suppose there is very little you can do.

              – enzotib
              Sep 27 '14 at 13:52














            51












            51








            51







            You should source your script, with



            . ./script


            or



            source ./script





            share|improve this answer













            You should source your script, with



            . ./script


            or



            source ./script






            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Jan 27 '12 at 20:12









            enzotibenzotib

            33.8k710395




            33.8k710395








            • 19





              the reason is that your script spawns a new shell process as a child of the current shell. Any environment changes you make in the child process cannot affect the parent. When you use . or source, you are not spawning a new child process, you are running the commands in the current shell.

              – glenn jackman
              Jan 27 '12 at 20:32






            • 1





              @glennjackman I have a similar problem and I have tried your solution but it logs me off from shell when I do . or source. Why is this happening ?

              – Patryk
              Feb 21 '12 at 13:03






            • 7





              @Patryk: maybe your script has an exit statement, so it is not suitable to be sourced.

              – enzotib
              Feb 21 '12 at 13:24











            • While source ./script works completely fine, sudo source ./script.sh says sudo: source: command not found. How can I do this using sudo?

              – 71GA
              Sep 27 '14 at 13:37






            • 1





              @71GA: depending on compilation preferences for sudo and depending on configuration settings in /etc/sudoers you can or cannot preserve your environment when running commands with sudo. I suggest you to try to source your script, and then run sudo with -E option to preserve the environment. If it does not work, I suppose there is very little you can do.

              – enzotib
              Sep 27 '14 at 13:52














            • 19





              the reason is that your script spawns a new shell process as a child of the current shell. Any environment changes you make in the child process cannot affect the parent. When you use . or source, you are not spawning a new child process, you are running the commands in the current shell.

              – glenn jackman
              Jan 27 '12 at 20:32






            • 1





              @glennjackman I have a similar problem and I have tried your solution but it logs me off from shell when I do . or source. Why is this happening ?

              – Patryk
              Feb 21 '12 at 13:03






            • 7





              @Patryk: maybe your script has an exit statement, so it is not suitable to be sourced.

              – enzotib
              Feb 21 '12 at 13:24











            • While source ./script works completely fine, sudo source ./script.sh says sudo: source: command not found. How can I do this using sudo?

              – 71GA
              Sep 27 '14 at 13:37






            • 1





              @71GA: depending on compilation preferences for sudo and depending on configuration settings in /etc/sudoers you can or cannot preserve your environment when running commands with sudo. I suggest you to try to source your script, and then run sudo with -E option to preserve the environment. If it does not work, I suppose there is very little you can do.

              – enzotib
              Sep 27 '14 at 13:52








            19




            19





            the reason is that your script spawns a new shell process as a child of the current shell. Any environment changes you make in the child process cannot affect the parent. When you use . or source, you are not spawning a new child process, you are running the commands in the current shell.

            – glenn jackman
            Jan 27 '12 at 20:32





            the reason is that your script spawns a new shell process as a child of the current shell. Any environment changes you make in the child process cannot affect the parent. When you use . or source, you are not spawning a new child process, you are running the commands in the current shell.

            – glenn jackman
            Jan 27 '12 at 20:32




            1




            1





            @glennjackman I have a similar problem and I have tried your solution but it logs me off from shell when I do . or source. Why is this happening ?

            – Patryk
            Feb 21 '12 at 13:03





            @glennjackman I have a similar problem and I have tried your solution but it logs me off from shell when I do . or source. Why is this happening ?

            – Patryk
            Feb 21 '12 at 13:03




            7




            7





            @Patryk: maybe your script has an exit statement, so it is not suitable to be sourced.

            – enzotib
            Feb 21 '12 at 13:24





            @Patryk: maybe your script has an exit statement, so it is not suitable to be sourced.

            – enzotib
            Feb 21 '12 at 13:24













            While source ./script works completely fine, sudo source ./script.sh says sudo: source: command not found. How can I do this using sudo?

            – 71GA
            Sep 27 '14 at 13:37





            While source ./script works completely fine, sudo source ./script.sh says sudo: source: command not found. How can I do this using sudo?

            – 71GA
            Sep 27 '14 at 13:37




            1




            1





            @71GA: depending on compilation preferences for sudo and depending on configuration settings in /etc/sudoers you can or cannot preserve your environment when running commands with sudo. I suggest you to try to source your script, and then run sudo with -E option to preserve the environment. If it does not work, I suppose there is very little you can do.

            – enzotib
            Sep 27 '14 at 13:52





            @71GA: depending on compilation preferences for sudo and depending on configuration settings in /etc/sudoers you can or cannot preserve your environment when running commands with sudo. I suggest you to try to source your script, and then run sudo with -E option to preserve the environment. If it does not work, I suppose there is very little you can do.

            – enzotib
            Sep 27 '14 at 13:52













            34














            When you run a script it gets its own shell and its own environment, which disappear again as soon as the script is finished. To keep the environment variables around, source the script into your current shell:



            $ source ./a.sh


            or equivalently (but a little more portably) use the POSIX dot command:



            $ . ./a.sh


            Then the definitions will be put into your current shell's environment and be inherited by any programs you launch from it.



            To be closer to running a script, . a.sh will find a.sh by searching the directories in the PATH environment variable.





            There are some subtleties in how these behave, and whether . and source are the same (or present at all). . ./a.sh will definitely behave the same in every POSIX-compatible shell, but source and ., and . a.sh and . ./a.sh, can vary. For Bash source and . are the same in all cases; for zsh source always checks the current directory first; ksh is essentially similar.



            If the script name is given as a path (containing a /), that path is used directly in all cases. The most portably reliable thing to do is . ./script or . /path/to/script.






            share|improve this answer






























              34














              When you run a script it gets its own shell and its own environment, which disappear again as soon as the script is finished. To keep the environment variables around, source the script into your current shell:



              $ source ./a.sh


              or equivalently (but a little more portably) use the POSIX dot command:



              $ . ./a.sh


              Then the definitions will be put into your current shell's environment and be inherited by any programs you launch from it.



              To be closer to running a script, . a.sh will find a.sh by searching the directories in the PATH environment variable.





              There are some subtleties in how these behave, and whether . and source are the same (or present at all). . ./a.sh will definitely behave the same in every POSIX-compatible shell, but source and ., and . a.sh and . ./a.sh, can vary. For Bash source and . are the same in all cases; for zsh source always checks the current directory first; ksh is essentially similar.



              If the script name is given as a path (containing a /), that path is used directly in all cases. The most portably reliable thing to do is . ./script or . /path/to/script.






              share|improve this answer




























                34












                34








                34







                When you run a script it gets its own shell and its own environment, which disappear again as soon as the script is finished. To keep the environment variables around, source the script into your current shell:



                $ source ./a.sh


                or equivalently (but a little more portably) use the POSIX dot command:



                $ . ./a.sh


                Then the definitions will be put into your current shell's environment and be inherited by any programs you launch from it.



                To be closer to running a script, . a.sh will find a.sh by searching the directories in the PATH environment variable.





                There are some subtleties in how these behave, and whether . and source are the same (or present at all). . ./a.sh will definitely behave the same in every POSIX-compatible shell, but source and ., and . a.sh and . ./a.sh, can vary. For Bash source and . are the same in all cases; for zsh source always checks the current directory first; ksh is essentially similar.



                If the script name is given as a path (containing a /), that path is used directly in all cases. The most portably reliable thing to do is . ./script or . /path/to/script.






                share|improve this answer















                When you run a script it gets its own shell and its own environment, which disappear again as soon as the script is finished. To keep the environment variables around, source the script into your current shell:



                $ source ./a.sh


                or equivalently (but a little more portably) use the POSIX dot command:



                $ . ./a.sh


                Then the definitions will be put into your current shell's environment and be inherited by any programs you launch from it.



                To be closer to running a script, . a.sh will find a.sh by searching the directories in the PATH environment variable.





                There are some subtleties in how these behave, and whether . and source are the same (or present at all). . ./a.sh will definitely behave the same in every POSIX-compatible shell, but source and ., and . a.sh and . ./a.sh, can vary. For Bash source and . are the same in all cases; for zsh source always checks the current directory first; ksh is essentially similar.



                If the script name is given as a path (containing a /), that path is used directly in all cases. The most portably reliable thing to do is . ./script or . /path/to/script.







                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Nov 28 '16 at 0:01

























                answered Jun 27 '14 at 0:07









                Michael HomerMichael Homer

                47.4k8124162




                47.4k8124162






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Unix & Linux Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f30189%2fhow-can-i-make-environment-variables-exported-in-a-shell-script-stick-around%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    Loup dans la culture

                    How to solve the problem of ntp “Unable to contact time server” from KDE?

                    ASUS Zenbook UX433/UX333 — Configure Touchpad-embedded numpad on Linux