“bash” command runs scripts in version 3.2, not 4.4
up vote
2
down vote
favorite
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
New contributor
|
show 2 more comments
up vote
2
down vote
favorite
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
New contributor
Welcome to Ask Different :) Please share the output or runningtype -a bash
andecho $SHELL
.
– Nimesh Neema
Nov 16 at 20:06
Please post the output ofecho $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 typingwhich 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
|
show 2 more comments
up vote
2
down vote
favorite
up vote
2
down vote
favorite
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
New contributor
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
terminal bash
New contributor
New contributor
edited Nov 16 at 22:21
New contributor
asked Nov 16 at 20:00
De Novo
1418
1418
New contributor
New contributor
Welcome to Ask Different :) Please share the output or runningtype -a bash
andecho $SHELL
.
– Nimesh Neema
Nov 16 at 20:06
Please post the output ofecho $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 typingwhich 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
|
show 2 more comments
Welcome to Ask Different :) Please share the output or runningtype -a bash
andecho $SHELL
.
– Nimesh Neema
Nov 16 at 20:06
Please post the output ofecho $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 typingwhich 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
|
show 2 more comments
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
.
New contributor
add a comment |
up vote
1
down vote
If you want to use bash 4.4 as your default shell do the following:
rename the
/bin/bash
file to something else (bash3
for example)
sudo mv /bin/bash /bin/bash3
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
.
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 enterbash
, it opens a new shell using version 3.2 andbash my_script.sh
runsmy_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 myPATH
variable. And, fyi, any subshells were 4.4 previously, it's just using the commandbash
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 thebash
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
|
show 5 more comments
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…
When executing a bash script with the commandbash my_script.sh
, the shebang is treated as a comment. The shebang is only interpreted if I givemy_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
add a comment |
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
.
New contributor
add a comment |
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
.
New contributor
add a comment |
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
.
New contributor
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
.
New contributor
edited Nov 17 at 2:53
New contributor
answered Nov 16 at 20:50
De Novo
1418
1418
New contributor
New contributor
add a comment |
add a comment |
up vote
1
down vote
If you want to use bash 4.4 as your default shell do the following:
rename the
/bin/bash
file to something else (bash3
for example)
sudo mv /bin/bash /bin/bash3
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
.
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 enterbash
, it opens a new shell using version 3.2 andbash my_script.sh
runsmy_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 myPATH
variable. And, fyi, any subshells were 4.4 previously, it's just using the commandbash
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 thebash
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
|
show 5 more comments
up vote
1
down vote
If you want to use bash 4.4 as your default shell do the following:
rename the
/bin/bash
file to something else (bash3
for example)
sudo mv /bin/bash /bin/bash3
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
.
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 enterbash
, it opens a new shell using version 3.2 andbash my_script.sh
runsmy_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 myPATH
variable. And, fyi, any subshells were 4.4 previously, it's just using the commandbash
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 thebash
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
|
show 5 more comments
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:
rename the
/bin/bash
file to something else (bash3
for example)
sudo mv /bin/bash /bin/bash3
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
.
If you want to use bash 4.4 as your default shell do the following:
rename the
/bin/bash
file to something else (bash3
for example)
sudo mv /bin/bash /bin/bash3
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
.
answered Nov 16 at 20:33
Allan
40k1257147
40k1257147
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 enterbash
, it opens a new shell using version 3.2 andbash my_script.sh
runsmy_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 myPATH
variable. And, fyi, any subshells were 4.4 previously, it's just using the commandbash
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 thebash
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
|
show 5 more comments
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 enterbash
, it opens a new shell using version 3.2 andbash my_script.sh
runsmy_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 myPATH
variable. And, fyi, any subshells were 4.4 previously, it's just using the commandbash
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 thebash
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
|
show 5 more comments
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…
When executing a bash script with the commandbash my_script.sh
, the shebang is treated as a comment. The shebang is only interpreted if I givemy_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
add a comment |
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…
When executing a bash script with the commandbash my_script.sh
, the shebang is treated as a comment. The shebang is only interpreted if I givemy_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
add a comment |
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…
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…
edited Nov 16 at 21:46
answered Nov 16 at 21:39
LangLangC
3,64731251
3,64731251
When executing a bash script with the commandbash my_script.sh
, the shebang is treated as a comment. The shebang is only interpreted if I givemy_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
add a comment |
When executing a bash script with the commandbash my_script.sh
, the shebang is treated as a comment. The shebang is only interpreted if I givemy_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
add a comment |
De Novo is a new contributor. Be nice, and check out our Code of Conduct.
De Novo is a new contributor. Be nice, and check out our Code of Conduct.
De Novo is a new contributor. Be nice, and check out our Code of Conduct.
De Novo is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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
Welcome to Ask Different :) Please share the output or running
type -a bash
andecho $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 typingwhich 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