Trying to export a path from inside a bash script [duplicate]

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP












0
















This question already has an answer here:



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

    2 answers



I am trying to put my whole environment set up into a single bash file. I am only hitting one issue. When I try to export a new path from inside the file it is not setting the path in the environment that the bash file was executed in. I want to do



>>sudo -H sh test.sh


Where test.sh is



bunch of installs

export PATH=/home/ubuntu/anaconda3/bin:$PATH

a second bunch of installs


I thought this was the purpose of eval so I tried



eval `export PATH=/home/ubuntu/anaconda3/bin:$PATH`


and even



eval `echo "export PATH=/home/ubuntu/anaconda3/bin:$PATH"`


but I can't access the command in the terminal. If I do it manually it works.



---------------UPDATE------------



The standard bash execution completes in a sub-shell so the environment variables are lost after execution. If you want to execute in the same shell then you



source test.sh


However, I need to be able to have full permissions in the execution so I need to use sudo. As explained here you cannot call sudo source but they did provide a hack to get it to work



source <(sudo cat /etc/environment)









share|improve this question















marked as duplicate by Kusalananda bash
Users with the  bash badge can single-handedly close bash questions as duplicates and reopen them as needed.

StackExchange.ready(function()
if (StackExchange.options.isMobile) return;

$('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
var $hover = $(this).addClass('hover-bound'),
$msg = $hover.siblings('.dupe-hammer-message');

$hover.hover(
function()
$hover.showInfoMessage('',
messageElement: $msg.clone().show(),
transient: false,
position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
dismissable: false,
relativeToBody: true
);
,
function()
StackExchange.helpers.removeMessages();

);
);
);
Mar 2 at 8:04


This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.






















    0
















    This question already has an answer here:



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

      2 answers



    I am trying to put my whole environment set up into a single bash file. I am only hitting one issue. When I try to export a new path from inside the file it is not setting the path in the environment that the bash file was executed in. I want to do



    >>sudo -H sh test.sh


    Where test.sh is



    bunch of installs

    export PATH=/home/ubuntu/anaconda3/bin:$PATH

    a second bunch of installs


    I thought this was the purpose of eval so I tried



    eval `export PATH=/home/ubuntu/anaconda3/bin:$PATH`


    and even



    eval `echo "export PATH=/home/ubuntu/anaconda3/bin:$PATH"`


    but I can't access the command in the terminal. If I do it manually it works.



    ---------------UPDATE------------



    The standard bash execution completes in a sub-shell so the environment variables are lost after execution. If you want to execute in the same shell then you



    source test.sh


    However, I need to be able to have full permissions in the execution so I need to use sudo. As explained here you cannot call sudo source but they did provide a hack to get it to work



    source <(sudo cat /etc/environment)









    share|improve this question















    marked as duplicate by Kusalananda bash
    Users with the  bash badge can single-handedly close bash questions as duplicates and reopen them as needed.

    StackExchange.ready(function()
    if (StackExchange.options.isMobile) return;

    $('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
    var $hover = $(this).addClass('hover-bound'),
    $msg = $hover.siblings('.dupe-hammer-message');

    $hover.hover(
    function()
    $hover.showInfoMessage('',
    messageElement: $msg.clone().show(),
    transient: false,
    position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
    dismissable: false,
    relativeToBody: true
    );
    ,
    function()
    StackExchange.helpers.removeMessages();

    );
    );
    );
    Mar 2 at 8:04


    This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.




















      0












      0








      0









      This question already has an answer here:



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

        2 answers



      I am trying to put my whole environment set up into a single bash file. I am only hitting one issue. When I try to export a new path from inside the file it is not setting the path in the environment that the bash file was executed in. I want to do



      >>sudo -H sh test.sh


      Where test.sh is



      bunch of installs

      export PATH=/home/ubuntu/anaconda3/bin:$PATH

      a second bunch of installs


      I thought this was the purpose of eval so I tried



      eval `export PATH=/home/ubuntu/anaconda3/bin:$PATH`


      and even



      eval `echo "export PATH=/home/ubuntu/anaconda3/bin:$PATH"`


      but I can't access the command in the terminal. If I do it manually it works.



      ---------------UPDATE------------



      The standard bash execution completes in a sub-shell so the environment variables are lost after execution. If you want to execute in the same shell then you



      source test.sh


      However, I need to be able to have full permissions in the execution so I need to use sudo. As explained here you cannot call sudo source but they did provide a hack to get it to work



      source <(sudo cat /etc/environment)









      share|improve this question

















      This question already has an answer here:



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

        2 answers



      I am trying to put my whole environment set up into a single bash file. I am only hitting one issue. When I try to export a new path from inside the file it is not setting the path in the environment that the bash file was executed in. I want to do



      >>sudo -H sh test.sh


      Where test.sh is



      bunch of installs

      export PATH=/home/ubuntu/anaconda3/bin:$PATH

      a second bunch of installs


      I thought this was the purpose of eval so I tried



      eval `export PATH=/home/ubuntu/anaconda3/bin:$PATH`


      and even



      eval `echo "export PATH=/home/ubuntu/anaconda3/bin:$PATH"`


      but I can't access the command in the terminal. If I do it manually it works.



      ---------------UPDATE------------



      The standard bash execution completes in a sub-shell so the environment variables are lost after execution. If you want to execute in the same shell then you



      source test.sh


      However, I need to be able to have full permissions in the execution so I need to use sudo. As explained here you cannot call sudo source but they did provide a hack to get it to work



      source <(sudo cat /etc/environment)




      This question already has an answer here:



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

        2 answers







      bash path eval






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Mar 4 at 19:14







      Keith

















      asked Mar 1 at 23:40









      KeithKeith

      1134




      1134




      marked as duplicate by Kusalananda bash
      Users with the  bash badge can single-handedly close bash questions as duplicates and reopen them as needed.

      StackExchange.ready(function()
      if (StackExchange.options.isMobile) return;

      $('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
      var $hover = $(this).addClass('hover-bound'),
      $msg = $hover.siblings('.dupe-hammer-message');

      $hover.hover(
      function()
      $hover.showInfoMessage('',
      messageElement: $msg.clone().show(),
      transient: false,
      position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
      dismissable: false,
      relativeToBody: true
      );
      ,
      function()
      StackExchange.helpers.removeMessages();

      );
      );
      );
      Mar 2 at 8:04


      This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.









      marked as duplicate by Kusalananda bash
      Users with the  bash badge can single-handedly close bash questions as duplicates and reopen them as needed.

      StackExchange.ready(function()
      if (StackExchange.options.isMobile) return;

      $('.dupe-hammer-message-hover:not(.hover-bound)').each(function()
      var $hover = $(this).addClass('hover-bound'),
      $msg = $hover.siblings('.dupe-hammer-message');

      $hover.hover(
      function()
      $hover.showInfoMessage('',
      messageElement: $msg.clone().show(),
      transient: false,
      position: my: 'bottom left', at: 'top center', offsetTop: -7 ,
      dismissable: false,
      relativeToBody: true
      );
      ,
      function()
      StackExchange.helpers.removeMessages();

      );
      );
      );
      Mar 2 at 8:04


      This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.






















          1 Answer
          1






          active

          oldest

          votes


















          0














          If you're using bash, then the short answer is to put your exported variables into one of the existing personal startup (or initialization) files. Variables exported in your terminal get lost when you close it. Variables exported in your script get lost when your script exits.



          There are other startup files which may or may not exist, but these are the most common ones:




          • ~/.bashrc

            • executed by bash for non-login shells



          • ~/.bash_profile

            • executed by bash for interactive login shells


            • ~/.profile is not read if this file exists

            • also reads ~/.bashrc on some systems

            • needs a (logout and) login to reread the file



          • ~/.profile

            • executed by the command interpreter for login shells

            • is not read when ~/.bash_profile exists

            • also reads ~/.bashrc on some systems

            • needs a (logout and) login to reread the file


          Or you create a new startup file with all your personal customizations and read it (source it) with source /path/to/myenvironment or . /path/to/myenvironment either on the command line / in your scripts or in one of the startup files mentioned above.



          Some example startup files are in package bash-doc in Ubuntu/Debian (install with sudo apt-get install bash-doc) and are installed to /usr/share/doc/bash/examples/startup-files/






          share|improve this answer

























          • Thanks but I am using EC2 so I will only go into this machine once. I want to have one setup script. I have read the posts erroneously marked as duplicate and I think the answer is to execute the script with 'sudo source test.sh'

            – Keith
            Mar 3 at 2:40











          • @Keith As environment files usually don't install things, you could put all your stuff into test.sh, make it executable and run it with sudo ./test.sh. Don't forget to add #!/bin/bash (bash) or #!/bin/sh (dash) as first line to your script. Or if you want an additional environment file, then put all your exported paths into file myenv and run sudo bash -c ". /path/to/myenv; /path/to/test.sh" (or sudo sh -c "..." for dash). If you export the path to your script in myenv, you could also write sudo bash -c ". /path/to/myenv; test.sh".

            – Freddy
            Mar 3 at 6:48











          • test.sh is not an environment file I just want one line in it to set up my environment during the install process. I have already tried all the things you mention but after executing the path is not set

            – Keith
            Mar 4 at 16:54











          • @Keith You can't set environment variables in a script. As soon as the script exits the variables are gone. You have to source an environment file before that, either automatically (~/.bashrc etc.) or manually.

            – Freddy
            Mar 4 at 16:58











          • Don't tell me what I can't do. :P This works "source <(sudo cat test.sh)" Now I can set up and install everything in one big script on EC2. If you can update your answer to say why only this hackish way to do it works I'll accept it.

            – Keith
            Mar 4 at 17:45

















          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          0














          If you're using bash, then the short answer is to put your exported variables into one of the existing personal startup (or initialization) files. Variables exported in your terminal get lost when you close it. Variables exported in your script get lost when your script exits.



          There are other startup files which may or may not exist, but these are the most common ones:




          • ~/.bashrc

            • executed by bash for non-login shells



          • ~/.bash_profile

            • executed by bash for interactive login shells


            • ~/.profile is not read if this file exists

            • also reads ~/.bashrc on some systems

            • needs a (logout and) login to reread the file



          • ~/.profile

            • executed by the command interpreter for login shells

            • is not read when ~/.bash_profile exists

            • also reads ~/.bashrc on some systems

            • needs a (logout and) login to reread the file


          Or you create a new startup file with all your personal customizations and read it (source it) with source /path/to/myenvironment or . /path/to/myenvironment either on the command line / in your scripts or in one of the startup files mentioned above.



          Some example startup files are in package bash-doc in Ubuntu/Debian (install with sudo apt-get install bash-doc) and are installed to /usr/share/doc/bash/examples/startup-files/






          share|improve this answer

























          • Thanks but I am using EC2 so I will only go into this machine once. I want to have one setup script. I have read the posts erroneously marked as duplicate and I think the answer is to execute the script with 'sudo source test.sh'

            – Keith
            Mar 3 at 2:40











          • @Keith As environment files usually don't install things, you could put all your stuff into test.sh, make it executable and run it with sudo ./test.sh. Don't forget to add #!/bin/bash (bash) or #!/bin/sh (dash) as first line to your script. Or if you want an additional environment file, then put all your exported paths into file myenv and run sudo bash -c ". /path/to/myenv; /path/to/test.sh" (or sudo sh -c "..." for dash). If you export the path to your script in myenv, you could also write sudo bash -c ". /path/to/myenv; test.sh".

            – Freddy
            Mar 3 at 6:48











          • test.sh is not an environment file I just want one line in it to set up my environment during the install process. I have already tried all the things you mention but after executing the path is not set

            – Keith
            Mar 4 at 16:54











          • @Keith You can't set environment variables in a script. As soon as the script exits the variables are gone. You have to source an environment file before that, either automatically (~/.bashrc etc.) or manually.

            – Freddy
            Mar 4 at 16:58











          • Don't tell me what I can't do. :P This works "source <(sudo cat test.sh)" Now I can set up and install everything in one big script on EC2. If you can update your answer to say why only this hackish way to do it works I'll accept it.

            – Keith
            Mar 4 at 17:45















          0














          If you're using bash, then the short answer is to put your exported variables into one of the existing personal startup (or initialization) files. Variables exported in your terminal get lost when you close it. Variables exported in your script get lost when your script exits.



          There are other startup files which may or may not exist, but these are the most common ones:




          • ~/.bashrc

            • executed by bash for non-login shells



          • ~/.bash_profile

            • executed by bash for interactive login shells


            • ~/.profile is not read if this file exists

            • also reads ~/.bashrc on some systems

            • needs a (logout and) login to reread the file



          • ~/.profile

            • executed by the command interpreter for login shells

            • is not read when ~/.bash_profile exists

            • also reads ~/.bashrc on some systems

            • needs a (logout and) login to reread the file


          Or you create a new startup file with all your personal customizations and read it (source it) with source /path/to/myenvironment or . /path/to/myenvironment either on the command line / in your scripts or in one of the startup files mentioned above.



          Some example startup files are in package bash-doc in Ubuntu/Debian (install with sudo apt-get install bash-doc) and are installed to /usr/share/doc/bash/examples/startup-files/






          share|improve this answer

























          • Thanks but I am using EC2 so I will only go into this machine once. I want to have one setup script. I have read the posts erroneously marked as duplicate and I think the answer is to execute the script with 'sudo source test.sh'

            – Keith
            Mar 3 at 2:40











          • @Keith As environment files usually don't install things, you could put all your stuff into test.sh, make it executable and run it with sudo ./test.sh. Don't forget to add #!/bin/bash (bash) or #!/bin/sh (dash) as first line to your script. Or if you want an additional environment file, then put all your exported paths into file myenv and run sudo bash -c ". /path/to/myenv; /path/to/test.sh" (or sudo sh -c "..." for dash). If you export the path to your script in myenv, you could also write sudo bash -c ". /path/to/myenv; test.sh".

            – Freddy
            Mar 3 at 6:48











          • test.sh is not an environment file I just want one line in it to set up my environment during the install process. I have already tried all the things you mention but after executing the path is not set

            – Keith
            Mar 4 at 16:54











          • @Keith You can't set environment variables in a script. As soon as the script exits the variables are gone. You have to source an environment file before that, either automatically (~/.bashrc etc.) or manually.

            – Freddy
            Mar 4 at 16:58











          • Don't tell me what I can't do. :P This works "source <(sudo cat test.sh)" Now I can set up and install everything in one big script on EC2. If you can update your answer to say why only this hackish way to do it works I'll accept it.

            – Keith
            Mar 4 at 17:45













          0












          0








          0







          If you're using bash, then the short answer is to put your exported variables into one of the existing personal startup (or initialization) files. Variables exported in your terminal get lost when you close it. Variables exported in your script get lost when your script exits.



          There are other startup files which may or may not exist, but these are the most common ones:




          • ~/.bashrc

            • executed by bash for non-login shells



          • ~/.bash_profile

            • executed by bash for interactive login shells


            • ~/.profile is not read if this file exists

            • also reads ~/.bashrc on some systems

            • needs a (logout and) login to reread the file



          • ~/.profile

            • executed by the command interpreter for login shells

            • is not read when ~/.bash_profile exists

            • also reads ~/.bashrc on some systems

            • needs a (logout and) login to reread the file


          Or you create a new startup file with all your personal customizations and read it (source it) with source /path/to/myenvironment or . /path/to/myenvironment either on the command line / in your scripts or in one of the startup files mentioned above.



          Some example startup files are in package bash-doc in Ubuntu/Debian (install with sudo apt-get install bash-doc) and are installed to /usr/share/doc/bash/examples/startup-files/






          share|improve this answer















          If you're using bash, then the short answer is to put your exported variables into one of the existing personal startup (or initialization) files. Variables exported in your terminal get lost when you close it. Variables exported in your script get lost when your script exits.



          There are other startup files which may or may not exist, but these are the most common ones:




          • ~/.bashrc

            • executed by bash for non-login shells



          • ~/.bash_profile

            • executed by bash for interactive login shells


            • ~/.profile is not read if this file exists

            • also reads ~/.bashrc on some systems

            • needs a (logout and) login to reread the file



          • ~/.profile

            • executed by the command interpreter for login shells

            • is not read when ~/.bash_profile exists

            • also reads ~/.bashrc on some systems

            • needs a (logout and) login to reread the file


          Or you create a new startup file with all your personal customizations and read it (source it) with source /path/to/myenvironment or . /path/to/myenvironment either on the command line / in your scripts or in one of the startup files mentioned above.



          Some example startup files are in package bash-doc in Ubuntu/Debian (install with sudo apt-get install bash-doc) and are installed to /usr/share/doc/bash/examples/startup-files/







          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Mar 2 at 7:53

























          answered Mar 2 at 7:06









          FreddyFreddy

          1,429210




          1,429210












          • Thanks but I am using EC2 so I will only go into this machine once. I want to have one setup script. I have read the posts erroneously marked as duplicate and I think the answer is to execute the script with 'sudo source test.sh'

            – Keith
            Mar 3 at 2:40











          • @Keith As environment files usually don't install things, you could put all your stuff into test.sh, make it executable and run it with sudo ./test.sh. Don't forget to add #!/bin/bash (bash) or #!/bin/sh (dash) as first line to your script. Or if you want an additional environment file, then put all your exported paths into file myenv and run sudo bash -c ". /path/to/myenv; /path/to/test.sh" (or sudo sh -c "..." for dash). If you export the path to your script in myenv, you could also write sudo bash -c ". /path/to/myenv; test.sh".

            – Freddy
            Mar 3 at 6:48











          • test.sh is not an environment file I just want one line in it to set up my environment during the install process. I have already tried all the things you mention but after executing the path is not set

            – Keith
            Mar 4 at 16:54











          • @Keith You can't set environment variables in a script. As soon as the script exits the variables are gone. You have to source an environment file before that, either automatically (~/.bashrc etc.) or manually.

            – Freddy
            Mar 4 at 16:58











          • Don't tell me what I can't do. :P This works "source <(sudo cat test.sh)" Now I can set up and install everything in one big script on EC2. If you can update your answer to say why only this hackish way to do it works I'll accept it.

            – Keith
            Mar 4 at 17:45

















          • Thanks but I am using EC2 so I will only go into this machine once. I want to have one setup script. I have read the posts erroneously marked as duplicate and I think the answer is to execute the script with 'sudo source test.sh'

            – Keith
            Mar 3 at 2:40











          • @Keith As environment files usually don't install things, you could put all your stuff into test.sh, make it executable and run it with sudo ./test.sh. Don't forget to add #!/bin/bash (bash) or #!/bin/sh (dash) as first line to your script. Or if you want an additional environment file, then put all your exported paths into file myenv and run sudo bash -c ". /path/to/myenv; /path/to/test.sh" (or sudo sh -c "..." for dash). If you export the path to your script in myenv, you could also write sudo bash -c ". /path/to/myenv; test.sh".

            – Freddy
            Mar 3 at 6:48











          • test.sh is not an environment file I just want one line in it to set up my environment during the install process. I have already tried all the things you mention but after executing the path is not set

            – Keith
            Mar 4 at 16:54











          • @Keith You can't set environment variables in a script. As soon as the script exits the variables are gone. You have to source an environment file before that, either automatically (~/.bashrc etc.) or manually.

            – Freddy
            Mar 4 at 16:58











          • Don't tell me what I can't do. :P This works "source <(sudo cat test.sh)" Now I can set up and install everything in one big script on EC2. If you can update your answer to say why only this hackish way to do it works I'll accept it.

            – Keith
            Mar 4 at 17:45
















          Thanks but I am using EC2 so I will only go into this machine once. I want to have one setup script. I have read the posts erroneously marked as duplicate and I think the answer is to execute the script with 'sudo source test.sh'

          – Keith
          Mar 3 at 2:40





          Thanks but I am using EC2 so I will only go into this machine once. I want to have one setup script. I have read the posts erroneously marked as duplicate and I think the answer is to execute the script with 'sudo source test.sh'

          – Keith
          Mar 3 at 2:40













          @Keith As environment files usually don't install things, you could put all your stuff into test.sh, make it executable and run it with sudo ./test.sh. Don't forget to add #!/bin/bash (bash) or #!/bin/sh (dash) as first line to your script. Or if you want an additional environment file, then put all your exported paths into file myenv and run sudo bash -c ". /path/to/myenv; /path/to/test.sh" (or sudo sh -c "..." for dash). If you export the path to your script in myenv, you could also write sudo bash -c ". /path/to/myenv; test.sh".

          – Freddy
          Mar 3 at 6:48





          @Keith As environment files usually don't install things, you could put all your stuff into test.sh, make it executable and run it with sudo ./test.sh. Don't forget to add #!/bin/bash (bash) or #!/bin/sh (dash) as first line to your script. Or if you want an additional environment file, then put all your exported paths into file myenv and run sudo bash -c ". /path/to/myenv; /path/to/test.sh" (or sudo sh -c "..." for dash). If you export the path to your script in myenv, you could also write sudo bash -c ". /path/to/myenv; test.sh".

          – Freddy
          Mar 3 at 6:48













          test.sh is not an environment file I just want one line in it to set up my environment during the install process. I have already tried all the things you mention but after executing the path is not set

          – Keith
          Mar 4 at 16:54





          test.sh is not an environment file I just want one line in it to set up my environment during the install process. I have already tried all the things you mention but after executing the path is not set

          – Keith
          Mar 4 at 16:54













          @Keith You can't set environment variables in a script. As soon as the script exits the variables are gone. You have to source an environment file before that, either automatically (~/.bashrc etc.) or manually.

          – Freddy
          Mar 4 at 16:58





          @Keith You can't set environment variables in a script. As soon as the script exits the variables are gone. You have to source an environment file before that, either automatically (~/.bashrc etc.) or manually.

          – Freddy
          Mar 4 at 16:58













          Don't tell me what I can't do. :P This works "source <(sudo cat test.sh)" Now I can set up and install everything in one big script on EC2. If you can update your answer to say why only this hackish way to do it works I'll accept it.

          – Keith
          Mar 4 at 17:45





          Don't tell me what I can't do. :P This works "source <(sudo cat test.sh)" Now I can set up and install everything in one big script on EC2. If you can update your answer to say why only this hackish way to do it works I'll accept it.

          – Keith
          Mar 4 at 17:45


          Popular posts from this blog

          How to check contact read email or not when send email to Individual?

          Bahrain

          Postfix configuration issue with fips on centos 7; mailgun relay