Program^WCompliance testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence.

-- Edsger Dijkstra (ish)

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!

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.

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.

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

(The OS shell of choice being zsh.)

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.

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.

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

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.

Apple added /bin/dash in Catalina, and the intention is probably to eventually to use dash as the implementation of sh: https://scriptingosx.com/2020/06/about-bash-zsh-sh-and-dash-....

As for why they haven't done it yet, I'd guess it's just to preserve backward compatibility with old scripts that rely on quirks of bash's sh compatibility mode.

Oh they added it to recovery too. Interesting.

> Until you have to gets your hands dirty and find small and bigger faults everywhere. For example, /bin/sh defaults to their ancient

It’s irrelevant. Neither POSIX nor the UNIX certification (or being a descendant of the UNIXes of old like the BSDs) requires a recent GNU userland (which is, as the name implies, not UNIX).

> > > such as MacOS, that are fully compliant with the POSIX standard

> > Until you have to gets your hands dirty and find small and bigger faults everywhere. For example, /bin/sh [...] doesn't work properly in these two parameter expansion cases:

> It’s irrelevant. Neither POSIX nor the UNIX certification [...] requires a recent GNU userland

Is it irrelevant?

If an implementation passes the conformance test suite, but is buggy according to the text of the spec in a way that is not caught by the test suite, can one really say it's "fully compliant with the POSIX standard"?

Is it the test suite that's the final arbiter of the POSIX standard, or is the text of the spec? Because I thought that the point of having a written spec, ratified by a standards body, is that the text of the spec defines what the spec is. It is the text of the spec that is submitted to the standards body, after all, not the test suite.

I said /bin/sh, not /bin/bash.

They dropped any utility that switched to GPLv3 because of v3's infectious patent clause that would've put their patent portfolio in danger.

The default shell on macOS has been zsh for over 4 years now, and they keep it up-to-date.