“bash” command runs scripts in version 3.2, not 4.4











up vote
2
down vote

favorite
1












Currently, in terminal, my default interactive shell is bash version 4.4. The OS ships with 3.2.



If I want to run a script (e.g., my_script.sh) using bash version 4.4, I can source it (source my_script.sh) or type it into my terminal directly. Though, in each case the script runs in my current shell. I can also give a script execute permissions and run it as a command, allowing the shebang to control which version of bash to use.



However, the command bash continues to use version 3.2. For example, if I run bash my_script.sh, the script will be executed in a new shell (which I want), but the older version of bash will be used (3.2). Similarly, if I just run bash with no argument, a new shell opens up using version 3.2 (recall, if I open a new window or tab in terminal, it uses my default shell, bash v. 4.4. The problem here is what happens when I use the command bash).



I've added the path to bash 4.4 on my machine (/usr/local/bin/bash) to my PATH variable in .bash_profile, and it's not being overwritten somewhere else (echo $PATH gives the expected result: the very first path is usr/local/bin/bash). I expected this to change the behavior of the command bash



I can use a workaround, by setting an alias (alias bash4='/usr/local/bin/bash'), but I don't have to use an alias for bash 3.2, or for upgraded versions of, e.g., python or R.



Is there something I'm missing? Is the alias solution the only option here?



EDITS



in response to comments:



SHELL is /usr/local/bin/bash, which is unsurprising, since that's my default login shell.



type -a bash is interesting...



bash is /bin/bash
bash is /usr/local/bin/bash
bash is /bin/bash
bash is /usr/local/bin/bash
bash is /bin/bash
bash is /usr/local/bin/bash
bash is /bin/bash
bash is /usr/local/bin/bash


My entire PATH is a mess, which may be the source of this problem.



/usr/local/bin/bash:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/local/bin/bash:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Library/Frameworks/Python.framework/Versions/3.5/bin:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Users/coltrane/Programming/Android_Development/sdk/platform-tools:/Library/Frameworks/R.framework/Resources/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Library/Frameworks/Python.framework/Versions/3.5/bin:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/local/bin/bash:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Library/Frameworks/Python.framework/Versions/3.5/bin:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Users/coltrane/Programming/Android_Development/sdk/platform-tools:/Library/Frameworks/R.framework/Resources/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Users/coltrane/Programming/Android_Development/sdk/platform-tools:/Library/Frameworks/R.framework/Resources/bin


unrelated problem with my path, i had inadvertently repeated $PATH in one line of my .bash_profile, (PATH=$PATH::$PATH) causing unwanted duplication










share|improve this question
























  • Welcome to Ask Different :) Please share the output or running type -a bash and echo $SHELL.
    – Nimesh Neema
    Nov 16 at 20:06










  • Please post the output of echo $PATH. The default bash is found in /bin/bash and I'm betting it comes before the path to bash v.4.
    – Allan
    Nov 16 at 20:10










  • @Alan nope. The only use of "bash" in $PATH is /usr/local/bin/bash, though it repeats many times... editing...
    – De Novo
    Nov 16 at 20:13












  • I mis-typed. Bash is found in /bin. Confirm this by typing which bash. But we still need to see your path.
    – Allan
    Nov 16 at 20:25










  • @Allan ahh, yes, /bin is in there multiple times, and I understood it should stay there. I put the path to bash 4.4 at the very beginning to solve this, though.
    – De Novo
    Nov 16 at 20:26















up vote
2
down vote

favorite
1












Currently, in terminal, my default interactive shell is bash version 4.4. The OS ships with 3.2.



If I want to run a script (e.g., my_script.sh) using bash version 4.4, I can source it (source my_script.sh) or type it into my terminal directly. Though, in each case the script runs in my current shell. I can also give a script execute permissions and run it as a command, allowing the shebang to control which version of bash to use.



However, the command bash continues to use version 3.2. For example, if I run bash my_script.sh, the script will be executed in a new shell (which I want), but the older version of bash will be used (3.2). Similarly, if I just run bash with no argument, a new shell opens up using version 3.2 (recall, if I open a new window or tab in terminal, it uses my default shell, bash v. 4.4. The problem here is what happens when I use the command bash).



I've added the path to bash 4.4 on my machine (/usr/local/bin/bash) to my PATH variable in .bash_profile, and it's not being overwritten somewhere else (echo $PATH gives the expected result: the very first path is usr/local/bin/bash). I expected this to change the behavior of the command bash



I can use a workaround, by setting an alias (alias bash4='/usr/local/bin/bash'), but I don't have to use an alias for bash 3.2, or for upgraded versions of, e.g., python or R.



Is there something I'm missing? Is the alias solution the only option here?



EDITS



in response to comments:



SHELL is /usr/local/bin/bash, which is unsurprising, since that's my default login shell.



type -a bash is interesting...



bash is /bin/bash
bash is /usr/local/bin/bash
bash is /bin/bash
bash is /usr/local/bin/bash
bash is /bin/bash
bash is /usr/local/bin/bash
bash is /bin/bash
bash is /usr/local/bin/bash


My entire PATH is a mess, which may be the source of this problem.



/usr/local/bin/bash:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/local/bin/bash:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Library/Frameworks/Python.framework/Versions/3.5/bin:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Users/coltrane/Programming/Android_Development/sdk/platform-tools:/Library/Frameworks/R.framework/Resources/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Library/Frameworks/Python.framework/Versions/3.5/bin:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/local/bin/bash:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Library/Frameworks/Python.framework/Versions/3.5/bin:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Users/coltrane/Programming/Android_Development/sdk/platform-tools:/Library/Frameworks/R.framework/Resources/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Users/coltrane/Programming/Android_Development/sdk/platform-tools:/Library/Frameworks/R.framework/Resources/bin


unrelated problem with my path, i had inadvertently repeated $PATH in one line of my .bash_profile, (PATH=$PATH::$PATH) causing unwanted duplication










share|improve this question
























  • Welcome to Ask Different :) Please share the output or running type -a bash and echo $SHELL.
    – Nimesh Neema
    Nov 16 at 20:06










  • Please post the output of echo $PATH. The default bash is found in /bin/bash and I'm betting it comes before the path to bash v.4.
    – Allan
    Nov 16 at 20:10










  • @Alan nope. The only use of "bash" in $PATH is /usr/local/bin/bash, though it repeats many times... editing...
    – De Novo
    Nov 16 at 20:13












  • I mis-typed. Bash is found in /bin. Confirm this by typing which bash. But we still need to see your path.
    – Allan
    Nov 16 at 20:25










  • @Allan ahh, yes, /bin is in there multiple times, and I understood it should stay there. I put the path to bash 4.4 at the very beginning to solve this, though.
    – De Novo
    Nov 16 at 20:26













up vote
2
down vote

favorite
1









up vote
2
down vote

favorite
1






1





Currently, in terminal, my default interactive shell is bash version 4.4. The OS ships with 3.2.



If I want to run a script (e.g., my_script.sh) using bash version 4.4, I can source it (source my_script.sh) or type it into my terminal directly. Though, in each case the script runs in my current shell. I can also give a script execute permissions and run it as a command, allowing the shebang to control which version of bash to use.



However, the command bash continues to use version 3.2. For example, if I run bash my_script.sh, the script will be executed in a new shell (which I want), but the older version of bash will be used (3.2). Similarly, if I just run bash with no argument, a new shell opens up using version 3.2 (recall, if I open a new window or tab in terminal, it uses my default shell, bash v. 4.4. The problem here is what happens when I use the command bash).



I've added the path to bash 4.4 on my machine (/usr/local/bin/bash) to my PATH variable in .bash_profile, and it's not being overwritten somewhere else (echo $PATH gives the expected result: the very first path is usr/local/bin/bash). I expected this to change the behavior of the command bash



I can use a workaround, by setting an alias (alias bash4='/usr/local/bin/bash'), but I don't have to use an alias for bash 3.2, or for upgraded versions of, e.g., python or R.



Is there something I'm missing? Is the alias solution the only option here?



EDITS



in response to comments:



SHELL is /usr/local/bin/bash, which is unsurprising, since that's my default login shell.



type -a bash is interesting...



bash is /bin/bash
bash is /usr/local/bin/bash
bash is /bin/bash
bash is /usr/local/bin/bash
bash is /bin/bash
bash is /usr/local/bin/bash
bash is /bin/bash
bash is /usr/local/bin/bash


My entire PATH is a mess, which may be the source of this problem.



/usr/local/bin/bash:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/local/bin/bash:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Library/Frameworks/Python.framework/Versions/3.5/bin:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Users/coltrane/Programming/Android_Development/sdk/platform-tools:/Library/Frameworks/R.framework/Resources/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Library/Frameworks/Python.framework/Versions/3.5/bin:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/local/bin/bash:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Library/Frameworks/Python.framework/Versions/3.5/bin:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Users/coltrane/Programming/Android_Development/sdk/platform-tools:/Library/Frameworks/R.framework/Resources/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Users/coltrane/Programming/Android_Development/sdk/platform-tools:/Library/Frameworks/R.framework/Resources/bin


unrelated problem with my path, i had inadvertently repeated $PATH in one line of my .bash_profile, (PATH=$PATH::$PATH) causing unwanted duplication










share|improve this question















Currently, in terminal, my default interactive shell is bash version 4.4. The OS ships with 3.2.



If I want to run a script (e.g., my_script.sh) using bash version 4.4, I can source it (source my_script.sh) or type it into my terminal directly. Though, in each case the script runs in my current shell. I can also give a script execute permissions and run it as a command, allowing the shebang to control which version of bash to use.



However, the command bash continues to use version 3.2. For example, if I run bash my_script.sh, the script will be executed in a new shell (which I want), but the older version of bash will be used (3.2). Similarly, if I just run bash with no argument, a new shell opens up using version 3.2 (recall, if I open a new window or tab in terminal, it uses my default shell, bash v. 4.4. The problem here is what happens when I use the command bash).



I've added the path to bash 4.4 on my machine (/usr/local/bin/bash) to my PATH variable in .bash_profile, and it's not being overwritten somewhere else (echo $PATH gives the expected result: the very first path is usr/local/bin/bash). I expected this to change the behavior of the command bash



I can use a workaround, by setting an alias (alias bash4='/usr/local/bin/bash'), but I don't have to use an alias for bash 3.2, or for upgraded versions of, e.g., python or R.



Is there something I'm missing? Is the alias solution the only option here?



EDITS



in response to comments:



SHELL is /usr/local/bin/bash, which is unsurprising, since that's my default login shell.



type -a bash is interesting...



bash is /bin/bash
bash is /usr/local/bin/bash
bash is /bin/bash
bash is /usr/local/bin/bash
bash is /bin/bash
bash is /usr/local/bin/bash
bash is /bin/bash
bash is /usr/local/bin/bash


My entire PATH is a mess, which may be the source of this problem.



/usr/local/bin/bash:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/local/bin/bash:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Library/Frameworks/Python.framework/Versions/3.5/bin:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Users/coltrane/Programming/Android_Development/sdk/platform-tools:/Library/Frameworks/R.framework/Resources/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Library/Frameworks/Python.framework/Versions/3.5/bin:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/local/bin/bash:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Library/Frameworks/Python.framework/Versions/3.5/bin:/Users/coltrane/Programming/Unix_Workbench/Code/Commands:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/Library/TeX/texbin:/opt/X11/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Users/coltrane/Programming/Android_Development/sdk/platform-tools:/Library/Frameworks/R.framework/Resources/bin:/usr/local/git/bin:/Applications/anaconda/bin:/Users/coltrane/Programming/Android_Development/sdk/platform-tools:/Library/Frameworks/R.framework/Resources/bin


unrelated problem with my path, i had inadvertently repeated $PATH in one line of my .bash_profile, (PATH=$PATH::$PATH) causing unwanted duplication







terminal bash






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 16 at 22:21

























asked Nov 16 at 20:00









De Novo

1418




1418












  • Welcome to Ask Different :) Please share the output or running type -a bash and echo $SHELL.
    – Nimesh Neema
    Nov 16 at 20:06










  • Please post the output of echo $PATH. The default bash is found in /bin/bash and I'm betting it comes before the path to bash v.4.
    – Allan
    Nov 16 at 20:10










  • @Alan nope. The only use of "bash" in $PATH is /usr/local/bin/bash, though it repeats many times... editing...
    – De Novo
    Nov 16 at 20:13












  • I mis-typed. Bash is found in /bin. Confirm this by typing which bash. But we still need to see your path.
    – Allan
    Nov 16 at 20:25










  • @Allan ahh, yes, /bin is in there multiple times, and I understood it should stay there. I put the path to bash 4.4 at the very beginning to solve this, though.
    – De Novo
    Nov 16 at 20:26


















  • Welcome to Ask Different :) Please share the output or running type -a bash and echo $SHELL.
    – Nimesh Neema
    Nov 16 at 20:06










  • Please post the output of echo $PATH. The default bash is found in /bin/bash and I'm betting it comes before the path to bash v.4.
    – Allan
    Nov 16 at 20:10










  • @Alan nope. The only use of "bash" in $PATH is /usr/local/bin/bash, though it repeats many times... editing...
    – De Novo
    Nov 16 at 20:13












  • I mis-typed. Bash is found in /bin. Confirm this by typing which bash. But we still need to see your path.
    – Allan
    Nov 16 at 20:25










  • @Allan ahh, yes, /bin is in there multiple times, and I understood it should stay there. I put the path to bash 4.4 at the very beginning to solve this, though.
    – De Novo
    Nov 16 at 20:26
















Welcome to Ask Different :) Please share the output or running type -a bash and echo $SHELL.
– Nimesh Neema
Nov 16 at 20:06




Welcome to Ask Different :) Please share the output or running type -a bash and echo $SHELL.
– Nimesh Neema
Nov 16 at 20:06












Please post the output of echo $PATH. The default bash is found in /bin/bash and I'm betting it comes before the path to bash v.4.
– Allan
Nov 16 at 20:10




Please post the output of echo $PATH. The default bash is found in /bin/bash and I'm betting it comes before the path to bash v.4.
– Allan
Nov 16 at 20:10












@Alan nope. The only use of "bash" in $PATH is /usr/local/bin/bash, though it repeats many times... editing...
– De Novo
Nov 16 at 20:13






@Alan nope. The only use of "bash" in $PATH is /usr/local/bin/bash, though it repeats many times... editing...
– De Novo
Nov 16 at 20:13














I mis-typed. Bash is found in /bin. Confirm this by typing which bash. But we still need to see your path.
– Allan
Nov 16 at 20:25




I mis-typed. Bash is found in /bin. Confirm this by typing which bash. But we still need to see your path.
– Allan
Nov 16 at 20:25












@Allan ahh, yes, /bin is in there multiple times, and I understood it should stay there. I put the path to bash 4.4 at the very beginning to solve this, though.
– De Novo
Nov 16 at 20:26




@Allan ahh, yes, /bin is in there multiple times, and I understood it should stay there. I put the path to bash 4.4 at the very beginning to solve this, though.
– De Novo
Nov 16 at 20:26










3 Answers
3






active

oldest

votes

















up vote
3
down vote



accepted










The error here is that the first path in PATH was to the bash executable, instead of to the directory that contains the bash executable. For readers with similar problems: double check to make sure any path you're adding to your PATH variable resolves to a directory, not to a file.



Problem:



I had added the following to my .bash_profile:



PATH=/usr/local/bin/bash:$PATH



/usr/local/bin/bash is not a directory. It's a file (well, a symbolic link to a file). So, regardless of placing it at the very beginning of PATH, the command bash will not find an executable file named bash inside any directory in PATH until it gets to /bin.



Solution:



In .bash_profile, setting



PATH=/usr/local/bin:$PATH


Solves the problem. Now the command bash finds the executable inside /usr/local/bin before it gets to /bin.






share|improve this answer






























    up vote
    1
    down vote













    If you want to use bash 4.4 as your default shell do the following:





    1. rename the /bin/bash file to something else (bash3 for example)



      sudo mv /bin/bash /bin/bash3



    2. create a symlink from your /usr/local/bin/bash to /bin/bash



      sudo ln -s /usr/local/bin/bash /bin/bash



    Now, anytime you open a shell it will open the 4.x version of bash and if you ever need to run bash v3.x, simply invoke bash3.






    share|improve this answer





















    • Just to clarify, bash 4.4 already is my default shell. Any time I open a shell it already opens the 4.x version of bash. But when I'm in my default shell, if I enter bash, it opens a new shell using version 3.2 and bash my_script.sh runs my_script.sh in a new shell using version 3.2.
      – De Novo
      Nov 16 at 20:37












    • bash 4.4 is your interactive shell. Because of your path, any subshells are 3.x This solution makes certain you're using 4.4 first.
      – Allan
      Nov 16 at 20:48










    • Thanks for the help. It looks like your solution would work (+1), but I ended up deciding to fix my path instead of adding a link that might confuse me later. Your comments on my question above helped me recognize what I should have seen from the beginning: /usr/local/bin/bash is not a directory, so it's meaningless to add it to my PATH variable. And, fyi, any subshells were 4.4 previously, it's just using the command bash that wasn't working as expected (because of my path error).
      – De Novo
      Nov 16 at 20:53












    • I had appropriately set my default shell as /usr/local/bin/bash, which is why shells (and subshells) were 4.4, except when using the bash command.
      – De Novo
      Nov 16 at 21:00






    • 1




      Is this really safe? That messes with SIP protected Apple binaries that are, apart from being outdated – creating one reason for the OP problem –, also Apple patched and God knows how twisted/patched up by Apple. That means this quick & 'dirty' hack can and probably will cause quite unforeseen problems down the road. Apple delivers patch for bash. What then? Big update rolls in, almost nothing is documented as usual, symlink gets overwritten. Bash versions might differ in unsuspected ways. I'd consider this only if nothing but SecUpdates come in, where patches to bash are probably doumented.
      – LangLangC
      Nov 16 at 23:05


















    up vote
    0
    down vote













    Why not instruct the script explicitly to do your exact bidding?



    Do not start it with



    #!/bin/sh 


    or whatever your shebang is.



    But try as the first line of your bash script



    #!/usr/local/bin/bash 




    If the problems originates from trying to run




    When executing a bash script with the command bash my_script.sh, the shebang is treated as a comment. The shebang is only interpreted if I give my_script.sh execute permissions and run it as a command.




    Then it's till possible to force your will without a cleaned up PATH environment (although it's still recommended to clean that up) with using absolute paths:



    When executing a bash script with the command /usr/local/bin/bash my_script.sh



    But for those cases an alias to the full path bash might come in handy…






    share|improve this answer























    • When executing a bash script with the command bash my_script.sh, the shebang is treated as a comment. The shebang is only interpreted if I give my_script.sh execute permissions and run it as a command.
      – De Novo
      Nov 16 at 21:42






    • 1




      LangLang, that's a general principle re: when a shebang is interpreted vs. treated as a comment, not a problem I'm having :), but yes, the absolute path to the correct version worked before I fixed the path variable (and the alias to make it more convenient)
      – De Novo
      Nov 16 at 21:51











    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "118"
    };
    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',
    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%2fapple.stackexchange.com%2fquestions%2f342873%2fbash-command-runs-scripts-in-version-3-2-not-4-4%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    3 Answers
    3






    active

    oldest

    votes








    3 Answers
    3






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes








    up vote
    3
    down vote



    accepted










    The error here is that the first path in PATH was to the bash executable, instead of to the directory that contains the bash executable. For readers with similar problems: double check to make sure any path you're adding to your PATH variable resolves to a directory, not to a file.



    Problem:



    I had added the following to my .bash_profile:



    PATH=/usr/local/bin/bash:$PATH



    /usr/local/bin/bash is not a directory. It's a file (well, a symbolic link to a file). So, regardless of placing it at the very beginning of PATH, the command bash will not find an executable file named bash inside any directory in PATH until it gets to /bin.



    Solution:



    In .bash_profile, setting



    PATH=/usr/local/bin:$PATH


    Solves the problem. Now the command bash finds the executable inside /usr/local/bin before it gets to /bin.






    share|improve this answer



























      up vote
      3
      down vote



      accepted










      The error here is that the first path in PATH was to the bash executable, instead of to the directory that contains the bash executable. For readers with similar problems: double check to make sure any path you're adding to your PATH variable resolves to a directory, not to a file.



      Problem:



      I had added the following to my .bash_profile:



      PATH=/usr/local/bin/bash:$PATH



      /usr/local/bin/bash is not a directory. It's a file (well, a symbolic link to a file). So, regardless of placing it at the very beginning of PATH, the command bash will not find an executable file named bash inside any directory in PATH until it gets to /bin.



      Solution:



      In .bash_profile, setting



      PATH=/usr/local/bin:$PATH


      Solves the problem. Now the command bash finds the executable inside /usr/local/bin before it gets to /bin.






      share|improve this answer

























        up vote
        3
        down vote



        accepted







        up vote
        3
        down vote



        accepted






        The error here is that the first path in PATH was to the bash executable, instead of to the directory that contains the bash executable. For readers with similar problems: double check to make sure any path you're adding to your PATH variable resolves to a directory, not to a file.



        Problem:



        I had added the following to my .bash_profile:



        PATH=/usr/local/bin/bash:$PATH



        /usr/local/bin/bash is not a directory. It's a file (well, a symbolic link to a file). So, regardless of placing it at the very beginning of PATH, the command bash will not find an executable file named bash inside any directory in PATH until it gets to /bin.



        Solution:



        In .bash_profile, setting



        PATH=/usr/local/bin:$PATH


        Solves the problem. Now the command bash finds the executable inside /usr/local/bin before it gets to /bin.






        share|improve this answer














        The error here is that the first path in PATH was to the bash executable, instead of to the directory that contains the bash executable. For readers with similar problems: double check to make sure any path you're adding to your PATH variable resolves to a directory, not to a file.



        Problem:



        I had added the following to my .bash_profile:



        PATH=/usr/local/bin/bash:$PATH



        /usr/local/bin/bash is not a directory. It's a file (well, a symbolic link to a file). So, regardless of placing it at the very beginning of PATH, the command bash will not find an executable file named bash inside any directory in PATH until it gets to /bin.



        Solution:



        In .bash_profile, setting



        PATH=/usr/local/bin:$PATH


        Solves the problem. Now the command bash finds the executable inside /usr/local/bin before it gets to /bin.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited Nov 17 at 2:53

























        answered Nov 16 at 20:50









        De Novo

        1418




        1418
























            up vote
            1
            down vote













            If you want to use bash 4.4 as your default shell do the following:





            1. rename the /bin/bash file to something else (bash3 for example)



              sudo mv /bin/bash /bin/bash3



            2. create a symlink from your /usr/local/bin/bash to /bin/bash



              sudo ln -s /usr/local/bin/bash /bin/bash



            Now, anytime you open a shell it will open the 4.x version of bash and if you ever need to run bash v3.x, simply invoke bash3.






            share|improve this answer





















            • Just to clarify, bash 4.4 already is my default shell. Any time I open a shell it already opens the 4.x version of bash. But when I'm in my default shell, if I enter bash, it opens a new shell using version 3.2 and bash my_script.sh runs my_script.sh in a new shell using version 3.2.
              – De Novo
              Nov 16 at 20:37












            • bash 4.4 is your interactive shell. Because of your path, any subshells are 3.x This solution makes certain you're using 4.4 first.
              – Allan
              Nov 16 at 20:48










            • Thanks for the help. It looks like your solution would work (+1), but I ended up deciding to fix my path instead of adding a link that might confuse me later. Your comments on my question above helped me recognize what I should have seen from the beginning: /usr/local/bin/bash is not a directory, so it's meaningless to add it to my PATH variable. And, fyi, any subshells were 4.4 previously, it's just using the command bash that wasn't working as expected (because of my path error).
              – De Novo
              Nov 16 at 20:53












            • I had appropriately set my default shell as /usr/local/bin/bash, which is why shells (and subshells) were 4.4, except when using the bash command.
              – De Novo
              Nov 16 at 21:00






            • 1




              Is this really safe? That messes with SIP protected Apple binaries that are, apart from being outdated – creating one reason for the OP problem –, also Apple patched and God knows how twisted/patched up by Apple. That means this quick & 'dirty' hack can and probably will cause quite unforeseen problems down the road. Apple delivers patch for bash. What then? Big update rolls in, almost nothing is documented as usual, symlink gets overwritten. Bash versions might differ in unsuspected ways. I'd consider this only if nothing but SecUpdates come in, where patches to bash are probably doumented.
              – LangLangC
              Nov 16 at 23:05















            up vote
            1
            down vote













            If you want to use bash 4.4 as your default shell do the following:





            1. rename the /bin/bash file to something else (bash3 for example)



              sudo mv /bin/bash /bin/bash3



            2. create a symlink from your /usr/local/bin/bash to /bin/bash



              sudo ln -s /usr/local/bin/bash /bin/bash



            Now, anytime you open a shell it will open the 4.x version of bash and if you ever need to run bash v3.x, simply invoke bash3.






            share|improve this answer





















            • Just to clarify, bash 4.4 already is my default shell. Any time I open a shell it already opens the 4.x version of bash. But when I'm in my default shell, if I enter bash, it opens a new shell using version 3.2 and bash my_script.sh runs my_script.sh in a new shell using version 3.2.
              – De Novo
              Nov 16 at 20:37












            • bash 4.4 is your interactive shell. Because of your path, any subshells are 3.x This solution makes certain you're using 4.4 first.
              – Allan
              Nov 16 at 20:48










            • Thanks for the help. It looks like your solution would work (+1), but I ended up deciding to fix my path instead of adding a link that might confuse me later. Your comments on my question above helped me recognize what I should have seen from the beginning: /usr/local/bin/bash is not a directory, so it's meaningless to add it to my PATH variable. And, fyi, any subshells were 4.4 previously, it's just using the command bash that wasn't working as expected (because of my path error).
              – De Novo
              Nov 16 at 20:53












            • I had appropriately set my default shell as /usr/local/bin/bash, which is why shells (and subshells) were 4.4, except when using the bash command.
              – De Novo
              Nov 16 at 21:00






            • 1




              Is this really safe? That messes with SIP protected Apple binaries that are, apart from being outdated – creating one reason for the OP problem –, also Apple patched and God knows how twisted/patched up by Apple. That means this quick & 'dirty' hack can and probably will cause quite unforeseen problems down the road. Apple delivers patch for bash. What then? Big update rolls in, almost nothing is documented as usual, symlink gets overwritten. Bash versions might differ in unsuspected ways. I'd consider this only if nothing but SecUpdates come in, where patches to bash are probably doumented.
              – LangLangC
              Nov 16 at 23:05













            up vote
            1
            down vote










            up vote
            1
            down vote









            If you want to use bash 4.4 as your default shell do the following:





            1. rename the /bin/bash file to something else (bash3 for example)



              sudo mv /bin/bash /bin/bash3



            2. create a symlink from your /usr/local/bin/bash to /bin/bash



              sudo ln -s /usr/local/bin/bash /bin/bash



            Now, anytime you open a shell it will open the 4.x version of bash and if you ever need to run bash v3.x, simply invoke bash3.






            share|improve this answer












            If you want to use bash 4.4 as your default shell do the following:





            1. rename the /bin/bash file to something else (bash3 for example)



              sudo mv /bin/bash /bin/bash3



            2. create a symlink from your /usr/local/bin/bash to /bin/bash



              sudo ln -s /usr/local/bin/bash /bin/bash



            Now, anytime you open a shell it will open the 4.x version of bash and if you ever need to run bash v3.x, simply invoke bash3.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered Nov 16 at 20:33









            Allan

            40.1k1258148




            40.1k1258148












            • Just to clarify, bash 4.4 already is my default shell. Any time I open a shell it already opens the 4.x version of bash. But when I'm in my default shell, if I enter bash, it opens a new shell using version 3.2 and bash my_script.sh runs my_script.sh in a new shell using version 3.2.
              – De Novo
              Nov 16 at 20:37












            • bash 4.4 is your interactive shell. Because of your path, any subshells are 3.x This solution makes certain you're using 4.4 first.
              – Allan
              Nov 16 at 20:48










            • Thanks for the help. It looks like your solution would work (+1), but I ended up deciding to fix my path instead of adding a link that might confuse me later. Your comments on my question above helped me recognize what I should have seen from the beginning: /usr/local/bin/bash is not a directory, so it's meaningless to add it to my PATH variable. And, fyi, any subshells were 4.4 previously, it's just using the command bash that wasn't working as expected (because of my path error).
              – De Novo
              Nov 16 at 20:53












            • I had appropriately set my default shell as /usr/local/bin/bash, which is why shells (and subshells) were 4.4, except when using the bash command.
              – De Novo
              Nov 16 at 21:00






            • 1




              Is this really safe? That messes with SIP protected Apple binaries that are, apart from being outdated – creating one reason for the OP problem –, also Apple patched and God knows how twisted/patched up by Apple. That means this quick & 'dirty' hack can and probably will cause quite unforeseen problems down the road. Apple delivers patch for bash. What then? Big update rolls in, almost nothing is documented as usual, symlink gets overwritten. Bash versions might differ in unsuspected ways. I'd consider this only if nothing but SecUpdates come in, where patches to bash are probably doumented.
              – LangLangC
              Nov 16 at 23:05


















            • Just to clarify, bash 4.4 already is my default shell. Any time I open a shell it already opens the 4.x version of bash. But when I'm in my default shell, if I enter bash, it opens a new shell using version 3.2 and bash my_script.sh runs my_script.sh in a new shell using version 3.2.
              – De Novo
              Nov 16 at 20:37












            • bash 4.4 is your interactive shell. Because of your path, any subshells are 3.x This solution makes certain you're using 4.4 first.
              – Allan
              Nov 16 at 20:48










            • Thanks for the help. It looks like your solution would work (+1), but I ended up deciding to fix my path instead of adding a link that might confuse me later. Your comments on my question above helped me recognize what I should have seen from the beginning: /usr/local/bin/bash is not a directory, so it's meaningless to add it to my PATH variable. And, fyi, any subshells were 4.4 previously, it's just using the command bash that wasn't working as expected (because of my path error).
              – De Novo
              Nov 16 at 20:53












            • I had appropriately set my default shell as /usr/local/bin/bash, which is why shells (and subshells) were 4.4, except when using the bash command.
              – De Novo
              Nov 16 at 21:00






            • 1




              Is this really safe? That messes with SIP protected Apple binaries that are, apart from being outdated – creating one reason for the OP problem –, also Apple patched and God knows how twisted/patched up by Apple. That means this quick & 'dirty' hack can and probably will cause quite unforeseen problems down the road. Apple delivers patch for bash. What then? Big update rolls in, almost nothing is documented as usual, symlink gets overwritten. Bash versions might differ in unsuspected ways. I'd consider this only if nothing but SecUpdates come in, where patches to bash are probably doumented.
              – LangLangC
              Nov 16 at 23:05
















            Just to clarify, bash 4.4 already is my default shell. Any time I open a shell it already opens the 4.x version of bash. But when I'm in my default shell, if I enter bash, it opens a new shell using version 3.2 and bash my_script.sh runs my_script.sh in a new shell using version 3.2.
            – De Novo
            Nov 16 at 20:37






            Just to clarify, bash 4.4 already is my default shell. Any time I open a shell it already opens the 4.x version of bash. But when I'm in my default shell, if I enter bash, it opens a new shell using version 3.2 and bash my_script.sh runs my_script.sh in a new shell using version 3.2.
            – De Novo
            Nov 16 at 20:37














            bash 4.4 is your interactive shell. Because of your path, any subshells are 3.x This solution makes certain you're using 4.4 first.
            – Allan
            Nov 16 at 20:48




            bash 4.4 is your interactive shell. Because of your path, any subshells are 3.x This solution makes certain you're using 4.4 first.
            – Allan
            Nov 16 at 20:48












            Thanks for the help. It looks like your solution would work (+1), but I ended up deciding to fix my path instead of adding a link that might confuse me later. Your comments on my question above helped me recognize what I should have seen from the beginning: /usr/local/bin/bash is not a directory, so it's meaningless to add it to my PATH variable. And, fyi, any subshells were 4.4 previously, it's just using the command bash that wasn't working as expected (because of my path error).
            – De Novo
            Nov 16 at 20:53






            Thanks for the help. It looks like your solution would work (+1), but I ended up deciding to fix my path instead of adding a link that might confuse me later. Your comments on my question above helped me recognize what I should have seen from the beginning: /usr/local/bin/bash is not a directory, so it's meaningless to add it to my PATH variable. And, fyi, any subshells were 4.4 previously, it's just using the command bash that wasn't working as expected (because of my path error).
            – De Novo
            Nov 16 at 20:53














            I had appropriately set my default shell as /usr/local/bin/bash, which is why shells (and subshells) were 4.4, except when using the bash command.
            – De Novo
            Nov 16 at 21:00




            I had appropriately set my default shell as /usr/local/bin/bash, which is why shells (and subshells) were 4.4, except when using the bash command.
            – De Novo
            Nov 16 at 21:00




            1




            1




            Is this really safe? That messes with SIP protected Apple binaries that are, apart from being outdated – creating one reason for the OP problem –, also Apple patched and God knows how twisted/patched up by Apple. That means this quick & 'dirty' hack can and probably will cause quite unforeseen problems down the road. Apple delivers patch for bash. What then? Big update rolls in, almost nothing is documented as usual, symlink gets overwritten. Bash versions might differ in unsuspected ways. I'd consider this only if nothing but SecUpdates come in, where patches to bash are probably doumented.
            – LangLangC
            Nov 16 at 23:05




            Is this really safe? That messes with SIP protected Apple binaries that are, apart from being outdated – creating one reason for the OP problem –, also Apple patched and God knows how twisted/patched up by Apple. That means this quick & 'dirty' hack can and probably will cause quite unforeseen problems down the road. Apple delivers patch for bash. What then? Big update rolls in, almost nothing is documented as usual, symlink gets overwritten. Bash versions might differ in unsuspected ways. I'd consider this only if nothing but SecUpdates come in, where patches to bash are probably doumented.
            – LangLangC
            Nov 16 at 23:05










            up vote
            0
            down vote













            Why not instruct the script explicitly to do your exact bidding?



            Do not start it with



            #!/bin/sh 


            or whatever your shebang is.



            But try as the first line of your bash script



            #!/usr/local/bin/bash 




            If the problems originates from trying to run




            When executing a bash script with the command bash my_script.sh, the shebang is treated as a comment. The shebang is only interpreted if I give my_script.sh execute permissions and run it as a command.




            Then it's till possible to force your will without a cleaned up PATH environment (although it's still recommended to clean that up) with using absolute paths:



            When executing a bash script with the command /usr/local/bin/bash my_script.sh



            But for those cases an alias to the full path bash might come in handy…






            share|improve this answer























            • When executing a bash script with the command bash my_script.sh, the shebang is treated as a comment. The shebang is only interpreted if I give my_script.sh execute permissions and run it as a command.
              – De Novo
              Nov 16 at 21:42






            • 1




              LangLang, that's a general principle re: when a shebang is interpreted vs. treated as a comment, not a problem I'm having :), but yes, the absolute path to the correct version worked before I fixed the path variable (and the alias to make it more convenient)
              – De Novo
              Nov 16 at 21:51















            up vote
            0
            down vote













            Why not instruct the script explicitly to do your exact bidding?



            Do not start it with



            #!/bin/sh 


            or whatever your shebang is.



            But try as the first line of your bash script



            #!/usr/local/bin/bash 




            If the problems originates from trying to run




            When executing a bash script with the command bash my_script.sh, the shebang is treated as a comment. The shebang is only interpreted if I give my_script.sh execute permissions and run it as a command.




            Then it's till possible to force your will without a cleaned up PATH environment (although it's still recommended to clean that up) with using absolute paths:



            When executing a bash script with the command /usr/local/bin/bash my_script.sh



            But for those cases an alias to the full path bash might come in handy…






            share|improve this answer























            • When executing a bash script with the command bash my_script.sh, the shebang is treated as a comment. The shebang is only interpreted if I give my_script.sh execute permissions and run it as a command.
              – De Novo
              Nov 16 at 21:42






            • 1




              LangLang, that's a general principle re: when a shebang is interpreted vs. treated as a comment, not a problem I'm having :), but yes, the absolute path to the correct version worked before I fixed the path variable (and the alias to make it more convenient)
              – De Novo
              Nov 16 at 21:51













            up vote
            0
            down vote










            up vote
            0
            down vote









            Why not instruct the script explicitly to do your exact bidding?



            Do not start it with



            #!/bin/sh 


            or whatever your shebang is.



            But try as the first line of your bash script



            #!/usr/local/bin/bash 




            If the problems originates from trying to run




            When executing a bash script with the command bash my_script.sh, the shebang is treated as a comment. The shebang is only interpreted if I give my_script.sh execute permissions and run it as a command.




            Then it's till possible to force your will without a cleaned up PATH environment (although it's still recommended to clean that up) with using absolute paths:



            When executing a bash script with the command /usr/local/bin/bash my_script.sh



            But for those cases an alias to the full path bash might come in handy…






            share|improve this answer














            Why not instruct the script explicitly to do your exact bidding?



            Do not start it with



            #!/bin/sh 


            or whatever your shebang is.



            But try as the first line of your bash script



            #!/usr/local/bin/bash 




            If the problems originates from trying to run




            When executing a bash script with the command bash my_script.sh, the shebang is treated as a comment. The shebang is only interpreted if I give my_script.sh execute permissions and run it as a command.




            Then it's till possible to force your will without a cleaned up PATH environment (although it's still recommended to clean that up) with using absolute paths:



            When executing a bash script with the command /usr/local/bin/bash my_script.sh



            But for those cases an alias to the full path bash might come in handy…







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Nov 16 at 21:46

























            answered Nov 16 at 21:39









            LangLangC

            3,64731251




            3,64731251












            • When executing a bash script with the command bash my_script.sh, the shebang is treated as a comment. The shebang is only interpreted if I give my_script.sh execute permissions and run it as a command.
              – De Novo
              Nov 16 at 21:42






            • 1




              LangLang, that's a general principle re: when a shebang is interpreted vs. treated as a comment, not a problem I'm having :), but yes, the absolute path to the correct version worked before I fixed the path variable (and the alias to make it more convenient)
              – De Novo
              Nov 16 at 21:51


















            • When executing a bash script with the command bash my_script.sh, the shebang is treated as a comment. The shebang is only interpreted if I give my_script.sh execute permissions and run it as a command.
              – De Novo
              Nov 16 at 21:42






            • 1




              LangLang, that's a general principle re: when a shebang is interpreted vs. treated as a comment, not a problem I'm having :), but yes, the absolute path to the correct version worked before I fixed the path variable (and the alias to make it more convenient)
              – De Novo
              Nov 16 at 21:51
















            When executing a bash script with the command bash my_script.sh, the shebang is treated as a comment. The shebang is only interpreted if I give my_script.sh execute permissions and run it as a command.
            – De Novo
            Nov 16 at 21:42




            When executing a bash script with the command bash my_script.sh, the shebang is treated as a comment. The shebang is only interpreted if I give my_script.sh execute permissions and run it as a command.
            – De Novo
            Nov 16 at 21:42




            1




            1




            LangLang, that's a general principle re: when a shebang is interpreted vs. treated as a comment, not a problem I'm having :), but yes, the absolute path to the correct version worked before I fixed the path variable (and the alias to make it more convenient)
            – De Novo
            Nov 16 at 21:51




            LangLang, that's a general principle re: when a shebang is interpreted vs. treated as a comment, not a problem I'm having :), but yes, the absolute path to the correct version worked before I fixed the path variable (and the alias to make it more convenient)
            – De Novo
            Nov 16 at 21:51


















             

            draft saved


            draft discarded



















































             


            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fapple.stackexchange.com%2fquestions%2f342873%2fbash-command-runs-scripts-in-version-3-2-not-4-4%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

            Plaza Victoria

            In PowerPoint, is there a keyboard shortcut for bulleted / numbered list?

            How to put 3 figures in Latex with 2 figures side by side and 1 below these side by side images but in...