_mbsetupuser uses /bin/bash

With considerable care I have developed a validation of user login environment. Bash is the most universal shell, and for compatibility with other (BSD/Linux) systems, it has been chosen for the validated environment. This environment consists primarily of tooling exported as functions, and local data paths exported as variables.


There is a very high reliability with any components using this environment because the required functions are tested with a check sum, basically "declare -f {function name} | cksum" is tested to have a particular value, or the env validation fails.


However, it has come to my attention that the bash version shipping with OSX is 3.2.57 from 2007, while a more recent version, eg 5.1.16 from 2020 is standard on the other systems. As a result, diffs like below are mucking up the check sum process:



12c12
<     };
---
>     }
35c35
<         cat 1>&2  <<-EOF
---
>         cat 1>&2 <<-EOF


This failure to maintain current versions of platform software creates a full stop in the quality process, with no particularly good work arounds.


These Mac systems do have brew installed, so it's nominal to install current bash that way. However, the brew path is at the end of the PATH env, so the brew binaries don't convolute any OSX operations. There is also an expectation for "/usr/bin/env bash" to get the right shell.


It was with great reluctance that I updated /etc/shells so that I could use brew's bash for my login shell and have consistency with other systems. I'm inclined to simply take away the exec bit from /bin/bash for minimal impact on the installed system, but I see that a (certainly not agile) OSX workflow depends on the /bin/bash login shell, _mbsetupuser. Why not /bin/sh? Why not update bash?


I have created an alternate admin user, which doesn't depend on the brew bash, least I run into problems. How badly will I break my system if I remove the exec bit from /bin/bash? In the course of application development, I start new login shells with a cleared environment, more or less continuously. How can I utilize a version of bash for my login shell that is newer then the 2007 version (15 years old now)? Should I overwrite /bin/bash with a static linked modern version?


If /bin/bash is not supported why is it in /etc/shells? Is _mbsetupuser the only OSX workflow that requires it? If it is supported, why is it such an old version? Maybe it should be moved to /legacy/bin where administrative tasks can find it? What's the best way to get a modern bash in the front of my path, and as my login shell?



Posted on Sep 26, 2022 3:22 AM

Reply
Question marked as Top-ranking reply

Posted on Sep 26, 2022 4:09 AM

Bash cannot be updated, as anything beyond the current macOS bash version is GPLv3 licensed, and poison to any proprietary vendor.


The inability to upgrade bash is the reason the user account default shell has been switched to zsh, which does NOT have the poisoned GPLv3 license.


Why _mbsetupuser uses /bin/bash I do not know.


Rather than modify /etc/shells, you could have .bash_profile test for an environment variable, if not set, set the variable, then exec /opt/Homebrew/bin/bash -l. The 2nd time .bash_profile runs, the environment variable will be set and you will be running a newer version of bash. Then you .bash_profile can set your PATH so the newer version of bash is found first via /usr/bin/env bash.


if you want Apple to ship a newer version of bash, then lobby the Open Software Foundation to remove the “poison pill” they put into the GPLv3 license, then re-license bash with the proprietary vendor friendly license.


Or rewrite your script(s) to find the latest bash version and use that instead of GPLv2 bash Apple is limited to shipping.

Similar questions

5 replies
Question marked as Top-ranking reply

Sep 26, 2022 4:09 AM in response to Georgalis

Bash cannot be updated, as anything beyond the current macOS bash version is GPLv3 licensed, and poison to any proprietary vendor.


The inability to upgrade bash is the reason the user account default shell has been switched to zsh, which does NOT have the poisoned GPLv3 license.


Why _mbsetupuser uses /bin/bash I do not know.


Rather than modify /etc/shells, you could have .bash_profile test for an environment variable, if not set, set the variable, then exec /opt/Homebrew/bin/bash -l. The 2nd time .bash_profile runs, the environment variable will be set and you will be running a newer version of bash. Then you .bash_profile can set your PATH so the newer version of bash is found first via /usr/bin/env bash.


if you want Apple to ship a newer version of bash, then lobby the Open Software Foundation to remove the “poison pill” they put into the GPLv3 license, then re-license bash with the proprietary vendor friendly license.


Or rewrite your script(s) to find the latest bash version and use that instead of GPLv2 bash Apple is limited to shipping.

Sep 28, 2022 5:44 PM in response to Georgalis

Here is what I ended up with. Kinda ugly but that's needful under the circumstance... I've restored /etc/shells to default, and reset my user shell to /bin/bash and per BobHarris' suggestion, I conditionally exec homebrew bash, as needed, from the top of my profile:

# For Bourne-compatible shells (bash,ksh,zsh,sh)

# for interactive sessions only
/usr/bin/tty -s || return

# if running /bin/bash on a mac with homebrew bash available, switch
ps | grep "^[ ]*$$ " | grep -q bash 2>/dev/null \
  && { test -x /opt/homebrew/bin/bash \
        && { expr "$(/opt/homebrew/bin/bash --version)" \
            : "GNU bash, version ${BASH_VERSINFO[0]}\.${BASH_VERSINFO[1]}\.${BASH_VERSINFO[2]}" >/dev/null \
            || { # set SHELL and exec homebrew bash
                export SHELL="/opt/homebrew/bin/bash"
                exec env -i TERM="$TERM" COLORTERM="$COLORTERM" \
                SHELL="$SHELL" HOME="$HOME" LOGNAME="$LOGNAME" USER="$USER" \
                SSH_AGENT_PID="$SSH_AGENT_PID" SSH_AUTH_SOCK="$SSH_AUTH_SOCK" \
                "${SHELL}" -l
               } # BASH_VERSINFO doesn't match homebrew version
          } || return 1 # exec homebrew bash failed
     } || true # homebrew not available


Because I reload my shells a lot, I also added this:

[ "${SHELL##*/}" = "bash" ] && { # restore login env
    alias _env='exec env -i TERM="$TERM" COLORTERM="$COLORTERM" \
                SHELL="$SHELL" HOME="$HOME" LOGNAME="$LOGNAME" USER="$USER" \
                SSH_AGENT_PID="$SSH_AGENT_PID" SSH_AUTH_SOCK="$SSH_AUTH_SOCK" \
                "${SHELL}" -l'
    }

Some verbosity with "|| return 1" might be helpful, but meh.

Sep 26, 2022 4:15 AM in response to Georgalis

Georgalis wrote:

Why not update bash?

Years ago, the bash project changed it licensing specifically so Apple couldn’t use it.

I have created an alternate admin user, which doesn't depend on the brew bash, least I run into problems. How badly will I break my system if I remove the exec bit from /bin/bash?

The operating system is on a cryptographically sealed, read-only volume. You won’t be able to change it.

How can I utilize a version of bash for my login shell that is newer then the 2007 version (15 years old now)?

Use the PATH environment. You can modify the path systemwide using the paths.d mechanism.

Should I overwrite /bin/bash with a static linked modern version?

See above.

If /bin/bash is not supported why is it in /etc/shells? Is _mbsetupuser the only OSX workflow that requires it?

No one can answer those kinds of questions. The Macintosh operating system itself isn’t supported much anymore, at least not on the level that you are expecting. It regularly gets the latest updates from iOS, but all of the UNIX/command-line stuff is frozen in time unless Apple really needs to make a change.

If it is supported, why is it such an old version?

GPL version 3. Apple is the only company that is affected.

Maybe it should be moved to /legacy/bin where administrative tasks can find it?

No such location exists. You could create it. And you could copy the bash executable if you wanted yet another version. But you can’t move.

What's the best way to get a modern bash in the front of my path, and as my login shell?

Use PATH, paths.d, or take Apple’s hint and adopt zsh.


Sep 26, 2022 2:55 PM in response to BobHarris

Thanks, I may be able to do something with testing env and conditionally exec the brew bash. This doesn't solve the dilemma of path sequence and I certainly don't want to conditionally exec through all my custom local scripts---there is very likely circumstances of pipelining or background processes for which this would cause havoc. So, I'll probably promote the brew path and navigate the consequences.


I am not going to waste my time lobbying the GNU evangelists, the methodology never has been and still does not produce better software vs BSD style licensing. Under the circumstances, the best solution would involve partitioning legacy GNU constrained binaries into a deprecated path, so they can be phased out, IMHO. But that would be on Apple, I'm just a HW consumer looking for better systems integration.

This thread has been closed by the system or the community team. You may vote for any posts you find helpful, or search the Community for additional answers.

_mbsetupuser uses /bin/bash

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.