[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.