mjhjmtu

I have read that POSIX compliant operating systems (for example: Linux) must have the sh shell.

But is it required for sh to be in the /bin directory, or can it be in any directory?

POSIX only mandates the /dev and /tmp directories to exist, and the /dev/null, /dev/tty, and /dev/console files. The standard utilities must exist, but there is no particular location specified. There may not be a /bin at all, and if there is it may not contain a sh, and if it does that may not be a POSIX sh.

You can get a valid PATH variable that includes the POSIX tools, including sh, with the getconf command:

$ PATH=$(getconf PATH)
$ sh

This can be useful on, for example, Solaris, where the default sh is not POSIX-compatible, but a compliant sh is provided and accessible in that way (because Solaris is a certified Unix). getconf PATH will include /usr/xpg4/bin at the front, which contains POSIX sh and a number of other required tools (including useless ones like cd).

No, it is not required for sh to be in /bin. It explicitly cites /bin, /usr/bin, and /usr/xpg4/bin as possible locations. The POSIX spec only requires that sh be in the PATH.

The POSIX spec states:

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.

For example, to determine the location of the standard sh utility:

command -v sh

On some implementations this might return:

/usr/xpg4/bin/sh

As others here have said, this is not strictly required for POSIX compliance.

But arguably compatibility with existing software is far more important (after all, the purpose of POSIX is to have certain things work on all conforming operating systems) and if an OS does not provide sh at /bin/sh, that will break some things.

Most obviously, scripts with #!/bin/sh rely on this path being standardized. This is not required to work; POSIX doesn't even require that #! lines are supported, although it mentions that such functionality is common:

Another way that some historical implementations handle shell scripts is by recognizing the first two bytes of the file as the character string "#!" and using the remainder of the first line of the file as the name of the command interpreter to execute.

But if that isn't supported, a lot of existing software will break or require additional work to port.