[eadmund]

It really says something about how much Apple cares about restricting its users’ freedom versus implementing functionality for those users that in 17 years they haven’t been bothered to either write their own /bin/sh, fix the ca. 2007 bash they do ship or just ship a newer, GPLv3 bash.

And it really says something about how important it is to license one’s software under GPLv3 or similar!

[icedchai]

They basically want you to use zsh... It's been the default shell for a while. If you want a newer version of bash, install it yourself with brew or macports.

[paulddraper]

I think it's best to consider MacOS not having bash by default.

(The OS shell of choice being zsh.)

[BoingBoomTschak]

What's even more comical is that they also ship dash, as shown in my example! But the reason why is obvious: people using a /bin/sh shebang with bash features.

So I understand, but patching bash to fix the --posix mode should still be done.

[glhaynes]

That might hold more weight for me if it weren't the easiest thing in the world to install bash! Like literally `brew install bash` will do it, right? That way I'm not reliant on Apple at all, which seems optimal when we're talking about features they don't build and that aren't their focus. I'm very happy to let Apple do the things they're good at and the community do the things they're good at.

[BoingBoomTschak]

Scripts using #!/bin/sh instead of #!/usr/bin/env (ba)sh won't use your shiny new shell. Including scripts deep inside the build system of misc. software that you won't modify.

The only way is to set their strange /etc/private symlink (cf sh(1)) to change what /bin/sh execs, and to do it again after each update which resets it.

[vorakl]

I wonder what is the origin of this "/bin/sh" and why it's often assumed that sh is in /bin by default. The standard is pretty clear about that:

"Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in."

"Furthermore, on systems that support executable scripts (the "#!" construct), it is recommended that applications using executable scripts install them using getconf PATH to determine the shell pathname and update the "#!" script appropriately as it is being installed (for example, with sed)."

Ref: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s...

So, apparently on systems, where sh resides in /bin, "getconf CONF" will return /bin . However, this is not always the case. For example, on my Fedora Linux it is /usr/bin

  $ getconf PATH
  /usr/bin
  $ ls -l /usr/bin/sh
  lrwxrwxrwx. 1 root root 4 Jan  2  2023 /usr/bin/sh -> bash
  $ ls -l /bin/sh
  lrwxrwxrwx. 1 root root 4 Jan  2  2023 /bin/sh -> bash
  $ ls -ld /bin
  lrwxrwxrwx. 1 root root 7 Aug  9  2022 /bin -> usr/bin

[BoingBoomTschak]

Probably the natural consequence of shebang limitations and the "chicken and egg problem" of env(1) that isn't always in /usr/bin.

If only we could write #!sh to do a PATH lookup...

Thanks for finding the exact POSIX section describing its own failings!

On Gentoo (with the recent merged-usr profile), getconf PATH returns "/bin:/usr/bin", heh.