Cuando sh es un enlace simbólico a bash o dash, bash se limita al cumplimiento POSIX, por lo que debería ser 100% compatible con sh?

De la diferencia entre bash y sh :

Regrese a la pregunta: si tiene /bin/shun enlace a bash, entonces bash no se comportará de la misma manera cuando se lo llama que /bin/shcuando se lo llama /bin/bash. Cuando se llama como sh, se limitará principalmente a la conformidad POSIX más un conjunto limitado de extensiones.

¿Significa que cada vez que me encuentro con un script de shell en Linux con un shebang para sh: #!/bin/shincluso si en esa distribución, bin/shes un enlace simbólico a otro shell, como dash o bash, debería ser 100% compatible con el shell bourne, ya que se limita a un conjunto limitado de extensiones? ¿Entonces podría ejecutarlos en FreeBSD? ¿Hay alguna excepción a eso? ¿O debería estar seguro de asumir que funcionará?

Entonces, si está en una distribución, ¿ bin/shhay un enlace simbólico a bin/bash, y el uso de un script #!/bin/shy el script contienen bashism, no se ejecutará, ya que bash querrá estar en modo sh?

No, si /bin/shes un enlace simbólico a golpe, golpe entra en modo de solo POSIX - a partir de bash :

Cuando se invoca como sh, bash ingresa al modo posix después de leer los archivos de inicio.

Si ahora busca el modo posix en la página de manual de bash , verá que algunos shell incorporados tienen gusto timeo se sourcecomportan de manera diferente. Eso es todo. bashishms como escribir functionantes de declarar una función o usar en sourcelugar de .seguir funcionando, pero los comandos pueden comportarse de manera diferente.

Entonces, si /bin/shes un enlace simbólico a /bin/bashtodos los bashishms típicos, todavía funciona.

Para obtener una lista bastante extensa de las diferencias en el modo Posix, consulte el manual de referencia de bash .

Parece haber cierta confusión en torno al caparazón de Bourne. El shell Bourne era un shell de Unix hace décadas, en los días previos a POSIX. Hoy en día "sh" es una implementación u otra de un shell que implementa la especificación POSIX, entre las cuales tenemos bash, pdksh, AT&T ksh, nuevos shells Almquist y sus derivados que se han hecho compatibles con POSIX (incluido el "sh" de algunos BSD) , otros BSDs se basan en pdksh y Debian ash (dash)). Incluso zsh tiene un modo en el que es principalmente compatible con POSIX.

El shell Bourne no es compatible con POSIX, y no se puede encontrar en muchos sistemas hoy en día. Donde se encuentra el shell Bourne o donde no lo es, siempre habrá una "sh" que sea compatible con POSIX (y no será el shell Bourne), generalmente /binmientras que una excepción notable (molesta) es Solaris.

Tenga en cuenta que antes del shell Bourne, y estamos hablando hace más de 30 años, "sh" era el shell Thompson. Ya no estamos escribiendo guiones compatibles con el shell Thompson. Del mismo modo, deberíamos dejar de pensar en "sh" como el shell Bourne.

Ahora "sh" es una especificación, no muchas variantes a veces incompatibles de una implementación. Eso hace que sea mucho más fácil escribir scripts portátiles. Solo sigue las especificaciones .

Eso va para "sh" y todas las utilidades estándar (sed, cut, tr ...)