¿"Sh" tiene que estar en el directorio "/ bin"?

He leído que los sistemas operativos compatibles con POSIX (por ejemplo: Linux) deben tener el shshell.

Pero, ¿se requiere para shestar en el /bindirectorio, o puede estar en cualquier directorio?

linux shell posix

— usuario270294
fuente

Siempre puede usar un enlace simbólico ya que /bin/sh, en la mayoría de los casos en Linux, ya es un enlace simbólico bash. Es solo que muchos scripts usan /bin/sh

— código rígido

Ahora que tiene la respuesta de que puede vivir donde quiera, puede preguntarse: ¿cómo puede escribir una línea shebang de manera portátil sh? Y la respuesta es: shebang tampoco forma parte de POSIX, por lo que el problema ni siquiera se presenta.

— Jörg W Mittag

@ JörgWMittag Sí, a veces es sorprendente cuántas de las cosas que consideramos características "estándar" de Unix no son realmente requeridas por POSIX.

— Barmar

Si usa o no un shebang es independiente de si la ruta /bin/shdebe existir en un sistema POSIX.

— chepner el

Al menos en sistemas derivados de Ubuntu, /bin/shes un enlace a dash. En los BSD, /bin/shno es un enlace sino un ejecutable separado, y ciertamente no bash.

— Rhialto apoya a Mónica el

Respuestas:

POSIX sólo se ordena la /devy /tmpdirectorios de existir , y los /dev/null, /dev/ttyy /dev/consolearchivos. Las utilidades estándar deben existir, pero no hay una ubicación específica especificada. Puede que no haya un /bin, y si lo hay, puede que no contenga un sh, y si lo hace, puede que no sea un POSIX sh.

Puede obtener una PATHvariable válida que incluya las herramientas POSIX, incluido sh, con el getconfcomando :

$ PATH=$(getconf PATH)
$ sh

Esto puede ser útil, por ejemplo, en Solaris, donde el valor predeterminado shno es compatible con POSIX , pero shse proporciona un dispositivo compatible y accesible de esa manera (porque Solaris es un Unix certificado ). getconf PATHincluirá /usr/xpg4/binen la parte delantera, que contiene POSIX shy una serie de otras herramientas necesarias ( incluidas las inútiles comocd ).

— Michael Homer
fuente

Re Solaris: ... a menos que esté ejecutando una instalación de "servidor pequeño" de Solaris, que omite muchas de las herramientas POSIX. Ver unix.stackexchange.com/q/360359/135943

— Comodín el

¿Los "inútiles"? Prefiero llamarlos redundantes.

— Mukesh Sai Kumar

Entonces, ¿cómo se encuentra getconf?

— Joshua

@MukeshSaiKumar un comando 'cd' independiente nunca puede funcionar

— OrangeDog

Bueno, "funcionará" solo por un valor de trabajo que, por ejemplo, pruebe si puede cambiar a un directorio, pero en realidad no deja el proceso que lo llamó allí. Sin embargo, esa es más funcionalidad que ninguna.

— Charles Duffy el

No, no se requiere para shestar adentro /bin. Se cita explícitamente /bin, /usr/biny /usr/xpg4/bincomo posibles ubicaciones. La especificación POSIX solo requiere que shesté en la RUTA.

La especificación POSIX dice:

Las aplicaciones deben tener en cuenta que no se puede suponer que la RUTA estándar del shell sea /bin/sho /usr/bin/sh, y debe determinarse mediante el interrogatorio del RUTA devuelto por la RUTA getconf, asegurando que el nombre de ruta devuelto sea un nombre de ruta absoluto y no un shell incorporado.

Por ejemplo, para determinar la ubicación de la utilidad estándar sh:

command -v sh

En algunas implementaciones, esto podría devolver:

/usr/xpg4/bin/sh

— John1024
fuente

Como han dicho otros aquí, esto no es estrictamente necesario para el cumplimiento de POSIX.

Pero podría decirse que la compatibilidad con el software existente es mucho más importante (después de todo, el propósito de POSIX es hacer que ciertas cosas funcionen en todos los sistemas operativos conformes) y si un sistema operativo no proporciona sh at /bin/sh, eso romperá algunas cosas.

Lo más obvio es que las secuencias de comandos se #!/bin/shbasan en esta ruta estandarizada. Esto no es obligatorio para trabajar; POSIX ni siquiera requiere que las #!líneas sean compatibles, aunque menciona que dicha funcionalidad es común :

Otra forma en que algunas implementaciones históricas manejan los scripts de shell es reconociendo los dos primeros bytes del archivo como la cadena de caracteres "#!" y usar el resto de la primera línea del archivo como el nombre del intérprete de comandos para ejecutar.

Pero si eso no es compatible, una gran cantidad de software existente se romperá o requerirá trabajo adicional para el puerto.

— Ian D. Scott
fuente