The default bash
on macOS is still bash v3:
$ bash --version
GNU bash, version 3.2.57(1)-release (x86_64-apple-darwin18)
Copyright (C) 2007 Free Software Foundation, Inc.
Just recently, bash v5 was released. The discrepancy comes from the fact that bash
has been licensed as GPL v3 since version 4. Apple does not include GPL v3 licensed tools with macOS.
However, nothing is keeping you from downloading and installing the latest bash
version.
New features include, among many other things, associated arrays (i.e. dictionaries) and better auto-completion setup.
While you would think this is a common desire, most pages I have found will simply point to Homebrew to download and install a newer bash version.
The main challenge with using brew
is that it does not work on the scale that MacAdmins require. brew
is designed for single user installation, where the user has administrator privileges. brew
’s workflows do not scale to large deployments controlled with a management system.
Ideally, there would be package installer for the latest bash version. Unfortunately, the bash project does not provide one.
In this post, I will show how you can install the latest bash version without brew
and how to build an installer package for deployment.
Manual Installation
This requires Xcode or the Developer Command Line Tools to be installed.
First, download the source for the latest bash version from this page. As of this writing the latest version is bash-5.0
and the file you want is bash-5.0.tar.gz
. Once downloaded, you can expand the archive in Finder by double-clicking.
Update: I have a post with some updated instructions to include the patches to bash 5.0.
Open a Terminal window and change directory to the newly expanded bash-5.0
directory. Then run the configure
script there.
$ cd ~/Downloads/bash-5.0
$ ./configure
The configure process will take a while, there will be plenty of messages showing progress.
Once the configure
process is complete. You can build bash
with the make
command.
$ make
This will build the bash
binary and the supporting files in the current directory. That’s not where we want it in the end, but it is probably a good idea see if the build process works. This will (again) take a while. There will be some odd looking warnings, but you can ignore those.
When make
succeeds, you can actually install bash
v5 with
$ sudo make install
This will build and install the bash
binary and supporting files in /usr/local/bin
and /usr/local
. sudo
is required to modify /usr/local
.
If you were just looking for a way to install bash
v5 without brew
, you are done!
There is more useful information in the rest of the post, though, so keep reading!
How the new and the old bash interact
By default, the bash v5 binary is called bash
and will be installed in /usr/local/bin
. The macOS default PATH
lists /usr/local/bin
before /bin
where the default bash v3 binary, also called bash
, is located.
This means, that when a user types bash
in to a shell, the version in /usr/local/bin
will be preferred over the pre-installed bash v3.
You can test this behavior in Terminal. Since the default shell has not yet been changed from /bin/bash
the Terminal still opens to bash v3. You can test this by showing the BASH_VERSION
environment variable:
$ echo $BASH_VERSION
3.2.57(1)-release
But when you then run bash
it will invoke /usr/local/bin/bash
, so it will run the new bash v5. It will show this in the prompt, but you can also verify the BASH_VERSION
.
$ bash
bash-5.0$ echo $BASH_VERSION
5.0.0(2)-release
This might be the setup you want, when you want to use bash v5 always. It might lead to some unexpected behavior for some users, though.
One option to avoid this ambiguity is to rename the binary in /usr/local/bin
to bash5
. But then other tools such as env
(mentioned below) will not find the binary any more.
- Scripting OS X: Where PATHs come from
Note: the PATH
in other contexts will likely not contain /usr/local/bin
and further confuse matters.
bash v5 and Scripting
Scripts using bash
, should have the full path to the binary in the shebang. This way, the script author can control whether a script is executed by the default bash v3 (/bin/bash
) or the newer bash v5 (/usr/local/bin/bash
or /usr/local/bin/bash5
).
It is often recommended to use the env
command in the shebang:
#!/usr/bin/env bash
The env
command will determine the path to the bash
binary in the current environment. (i.e. using the current PATH
) This is useful when the script has to run in various environments where the location of the bash binary is unknown, in other words across multiple Unix and Unix-like platforms. However, this renders the actual version of bash
that will interpret the script unpredictable.
For example, assume you have bash v5 installed in the default configuration (as /usr/local/bin/bash
. A script with the shebang #!/usr/bin/env bash
launched in the user environment (i.e. from Terminal) will use the newer bash
, as /usr/local/bin
comes before /bin
in the search order.
When you launch the same script in a different context, e.g. as an installation script, an AppleScript, or a management system, /usr/local/bin
will likely not be part of the PATH
in that environment. Then the env
shebang will choose /bin/bash
(v3). The script will be interpreted and might behave differently.
Administrators prefer certainty in their managed environments. Administrators should know the location and versions of the binaries on their systems. For management scripts, you should avoid env
and use the proper full path to the desired interpreter binary.
The solutions to resolve the ambiguity are
- use the full path to the binary in the shebang
- manage and update the additional custom version of
bash
with a management system - (optional) rename the newer
bash
binary tobash5
orbash4
(this also allows you to havebash
v4 andbash
v5 available on the same system) - Scripting OS X: On the Shebang
- Scripting OS X: Setting the PATH in Scripts
Changing a user’s default Shell to bash v5
Even though we have installed bash v5, the default shell of a new Terminal window will still use the built-in bash v3.
The path to the default shell is stored in the user record. You can directly change the UserShell
attribute with dscl
, in the ‘Advanced Options’ of the ‘Users & Groups’ preference pane, or in Directory Utility.
There is also a command to set the default shell:
$ chsh -s /usr/local/bin/bash
Changing shell for armin.
Password for armin:
chsh: /usr/local/bin/bash: non-standard shell
The chsh
(change shell) command will check for allowed shells in the /etc/shells
file. You can easily append a line with /usr/local/bin/bash
to this file, and then chsh
will work fine.
$ chsh -s /usr/local/bin/bash
Changing shell for armin.
Password for armin:
Note: if you choose to rename the bash
binary, you have to use the changed name in /etc/shells
and with chsh
.
Remember that just running chsh
will not change the shell in the current Terminal window. It is best to close the old Terminal window and open a new one to get the new shell.
Packaging bash v5 for mass deployment
While these steps to install and configure bash v5 on a single Mac are simple enough, they would not work well with a management system for hundreds or thousands of Macs. We want to wrap all the files that make install
creates into a package installer payload.
The --help
option of the configure
script yields this useful information:
By default,
make install' will install all the files in
/usr/local/bin,
/usr/local/libetc. You can specify an installation prefix other than
/usr/localusing
–prefix, for instance
–prefix=$HOME`.
When we run the configure script with the --prefix
option it creates a folder suitable as a payload for a package installer. We can then use pkgbuild
to build to create an installer pkg:
$ cd ~/Downloads/bash-5.0
$ mkdir payload
$ ./configure --prefix=/Users/armin/Downloads/bash-5.0/payload
$ make install
$ pkgbuild --root payload --install-location /usr/local --identifier org.gnu.bash --version 5.0 bash-5.0.pkg
pkgbuild: Inferring bundle components from contents of payload
pkgbuild: Wrote package to bash-5.0.pkg
(Note: the --prefix
argument requires an absolute path.)
Automate the package creation
So, we have our workflow for building an installer package to distribute and configure bash v5:
- download the archive
- extract the archive
- run
configure
with the--prefix
argument - run
make install
to create the files in a payload folder - optional: rename the resulting
bash
binary tobash5
to avoid conflicts - add a
postinstall
script that adds/usr/local/bin/bash[5]
to/etc/shells
if not yet present - build the installer with
pkgbuild
This sounds like a workflow ripe for automation. You can get the script from this repository.
You can pass a different (valid) bash version number as an argument to the script, e.g. 4.4.18
. (I did not test anything significantly older.) The script does not autodetect the latest version and defaults to version 5.0
when no argument is given. When an update to bash v5 is published, you will have to modify the version line or run the script with an argument.
I have not (yet) figured out how to detect the latest version from the download web page. An autopkg
recipe will have to wait for that. (If someone else wants to tackle that, please do!)
Greetings, just ran across your post, the latest version of bash can be found with this (on MacOS using curl, no wget by default). Here’s to hoping that all the tics, slashes, quotes, etc are faithfully reproduced in the command below:
“`
$ latestversion=$(curl -s https://ftp.gnu.org/gnu/bash/ | grep href | sed ‘s/.*href=”//’ | sed ‘s/”.*//’ | grep ‘bash-[0-9]*’ | grep -v doc | grep -v \/ | cut -c6-8 | sort -n | uniq | tail -1) ; echo “latest version == $latestversion”
latest version == 5.0
$
“`
Using $latest-version, you should be able to extract the tar.gz and tar.gz.sig files with a slightly modified curl
yeah, it’s useful
Hey there,
Great post.
At the beginning are you saying that you *can’t* use brew to install the latest version of bash, on your own, single user MacBook Pro, using sudo?
No. What I am saying is that brew does _not_ work well (or at all) at scale, i.e when you need to deploy bash5 (or anything) to dozens, or even hundreds or thousands of Macs.
Hi,
Great post.
Wanted to add. I recently upgraded to Catalina, and when I tried to run `./configure`
I got the error “cannot run C compiled programs”. apparently this is a somewhat generic issue that can be caused by multiple problems.
In this case, it turns out the that Catalina update (and Mojave too apparently) have deprecated the /usr/include directory.
[this](https://stackoverflow.com/questions/58278260/cant-compile-a-c-program-on-a-mac-after-upgrading-to-catalina-10-15/58278392#58278392) stack question has the solution that worked for me.
The instructions given worked for me on my production Catalina system as well as a clean Catalina install without problems.
Nevertheless, your link might help others who encounter the same problem. Thank you!
Armin, nice, thorough work as usual. A question for an individual user like me: what’s the downside of archiving the old bash v3 and putting v5 into /bin/bash so that any shebang points to the new one?
First,
/bin/bash
is protected by SIP. That should be your first warning sign. You would have to disable SIP to replace/bin/bash
(not recommended).
Second, there are hundreds and thousands of bash scripts from Apple and third parties, that you may not encounter directly but that will be running in installation processes or background tasks, that _assume_
/bin/bash
is version 3.2, not version 5. While most bash scripts should behave the same with the newer version, unforeseen problems with other software is bound to happen and will be really hard to diagnose.Third,
bash
depends on thereadline
command, you’d have to replace that with the latest version as well, with the same caveats and limitations.Finally, macOS updates might overwrite your replacement. So, even if all else is going well, you have to re-apply your change frequently.
It is safer to place bash v5 in its own location and use the full path in the shebang to make sure the script is executed with the version of bash you expect. If your scripts have to work cross-platform where the paths to the bash binary may differ, you can use
/usr/bin/env bash
as the shebang. This means ‘resolve the path to bash using the current environment and use that.’Thanks for sharing you knowledge.
Hi how can I remove the installed bash?
You remove the files it has installed. Most important are `/usr/local/bin/bash` and `/usr/local/bin/bashbug`. The process above installs a lot of other libraries and documentation files, but those will be mostly inert when you delete the binaries. You can get a full of list of files by building a pkg and listing the files from that pkg:
(Note: `.` in the list above refers to the install-location of the pkg which is `/usr/local`)
Thanks! Very good instructions. I learned several things along the way. And I’m now running GNU bash, version 5.0.17(1)-release (x86_64-apple-darwin19.5.0).
Wondering: under what conditions would it be good to update /etc/shells to include /usr/local/bin/bash:
/bin/bash
/bin/csh
/bin/dash
/bin/ksh
/bin/sh
/bin/tcsh
/bin/zsh
/usr/local/bin/bash
ted
There are a few tools that refer to this list, most importantly `chpass`, `chsh` and `chfn`. There are ways of changing the default shell without going through these tools (System Preferences, Directory Utility, `dscl`, Terminal). So, when you are the only user on your system, you don’t _need_ to update `/etc/shells`. But, you may end up in a confusing situation in the future where something might not work because `/usr/local/bin/bash` isn’t listed in that file, so it’s probably prudent.
Great instructions. Thanks!
Auto-complete (without a package manager) for Bash 5? Nice to have but not finding a clear win on how.
I wouldn’t know, I moved to zsh 😉
I agree on installing it in its own location. I think the location of /usr/local/bin is good enough. I set the default to be the bash 5.0 and wrote a script to test all three bash. I tested all three of them and the 5.0 came on top. I will do further testing.
I followed your instructions for installing bash 5.0 under macOS Catalina. (From your ebook as well as the blog.) The final step, sudo make install, generated error:
../../include/gettext.h:27:11: fatal error: ‘libintl.h’ file not found
How fix this?
I cannot recreate that problem. bash 5.0.18 works for me. I’d recommend deleting everything and starting over. You can also use the script I link to later in the post to create an installer pkg for you.
For a workaround, I installed the MacPorts port of bash 5.0.17. And then in Terminal’s Preferences > General, for the “Shells open with” I clicked the “Command (complete path)” radio button and entered /opt/local/bin/bash for the path.
One advantage of using bash from MacPorts is that it’s easy to update the port as part of my regular updating of all such ports.
Tried to compile exactly as per yr instruction. make stops with fatal error too many errors emited. With “make CFLAGS=”-ferror-limit=0″ it throws 1 warning and 37 errors generated. make: *** [siglist.o] Eror 1
No bash 5 on my macOS 10.15.7 now