¿Por qué nadie usa el verdadero shell Bourne como / bin / sh?

55

Me di cuenta de que básicamente ningún sistema con el que he trabajado tiene /bin/shun ejecutable real. Siempre es un enlace simbólico a dash, bashen modo POSIX, o algo similar.

¿Por qué? ¿Cuáles son las desventajas de usar el verdadero original /bin/sh? (¿Velocidad? ¿Licencias?)

shell history dash Strugee
fuente
3
Solo has usado Linux, ¿verdad? Solo he visto "sh como enlace simbólico" en Linux.
Greg Hewgill
No @GregHewgill las últimas versiones de Solaris han shenlace simbólico a ksh?
Gilles 'SO- deja de ser malvado'
1
@Gilles según una de las respuestas, sí, ya que Solaris 11. está vinculado a ksh.
Strugee
1
@GregHewgill También he usado Darwin, que tiene un enlace simbólico bash, IIRC.
Strugee
66
¿Qué quieres decir con el original / bin / sh ? ¿La cáscara de Thomson de Unix V1? El shell Bourne de Unix V7 que no tenía funciones ni comentarios ...? ¿El de SysIII, SysV, Solaris, HP / UX, la reimplementación de cenizas en BSD? Hoy en día shse basa en un estándar, lo que significa que podemos tener varias implementaciones que se comportarán de una manera clara y específica siempre que use la sintaxis estándar en su secuencia de comandos.
Stéphane Chazelas

Respuestas:

38

Supongo que la falta de características: sin historial de comandos, sin redirección elegante, sin edición de línea de comandos. BSD introdujo cshel shell C por esas razones. Otro factor es que el Bourne Shell original solo estuvo disponible recientemente en forma de código abierto . A menos que lo licenciara, no podría distribuirlo. Eso lo puso fuera del alcance de las distribuciones gratuitas y lo hizo ideológicamente desagradable para otras distribuciones, y * BSD.

Pero el código está disponible ahora. Puedes echar un vistazo, compilarlo, darle una vuelta.

Bruce Ediger
fuente
50
Y luego vuelva rápidamente a lo que estaba usando antes.
Ignacio Vazquez-Abrams
24
@strugee "" falta de características ": ¿por qué esto sería un problema?" Sí, buen punto ... ¿por qué los programadores usan cosas inútiles como ensamblar / C / lenguajes de alto nivel cuando cualquier cosa que puedas hacer con ellos ya puedes escribir? lenguaje de máquina directamente? El hecho es: características = aumento en la velocidad de desarrollo + mayor mantenibilidad = menos costos = mejor El uso shes exactamente como usar, bashexcepto que es: más lento, los programas son más largos y es más difícil de mantener.
Bakuriu
10
No es realmente la falta de características, sino el hecho de que POSIX exige que el shcomando ejecute un shell compatible con POSIX, lo que no es el shell Bourne heredado. Si bien POSIX no requiere shestar /bin/sh, ese es el directorio más lógico para que esté.
jlliagre
44
El historial de comandos de @Bakuriu y la edición de la línea de comandos son cosas que realmente no necesitarías para un script.
Strugee
44
@strugee Esas no son las únicas diferencias. Por ejemplo sh, no tiene expansión de tilde y arriostramiento, faltan algunos elementos integrados (por ejemplo , pushdy ) popd, selectno hay expansión aritmética. Faltan muchas variables, por ejemplo PIPESTATUS.
Bakuriu el
23

La afirmación en su pregunta es incorrecta. Solaris hasta la versión 10 está proporcionando el legado verdadero Bourne shell como /bin/sh. Esto se hizo para no romper la compatibilidad con scripts antiguos que podrían fallar con un shell diferente. Sin embargo, esta elección fue muy frustrante.

La mayoría, si no todas, las versiones restantes de Unix y Unix, incluido Solaris 11, proporcionan un shell compatible con /bin/shPOSIX porque POSIX exige que el shcomando inicie un shell POSIX, no el shell Bourne heredado que no es compatible. /bin/shes generalmente :

  • ksh88o ksh93en las implementaciones comerciales de Unix
  • un modificado bashen OS/X(aunque solía ser zsh)
  • una asho pdkshderivada en otraBSDs
  • basho dashen distribuciones Gnu / Linux.

No es necesariamente un enlace, pero puede ser un ejecutable real en muchos sistemas, pero Gnu / Linux.

Curiosamente, a pesar de lo que dice la respuesta más votada a su pregunta, no es la falta de características lo que lleva a los desarrolladores de distribución a instalar algo diferente al shell Bourne heredado, /bin/shsino el deseo de cumplir con POSIX lo más posible, es decir, comportarse como un Unix como sistema operativo. El hecho de que el shell POSIX tenga más funciones que el shell Bourne heredado es solo un efecto secundario de este objetivo de cumplimiento estándar.

También es un hecho que algunos shells, en particular bash, se comportan de manera diferente cuando se los llama sh, y esto elimina principalmente las características del shell, no al revés.

jlliagre
fuente
16

Por lo que sé, el shell Bourne original no podía ser utilizado por los BSD y el proyecto GNU, debido a su licencia.

En aquel entonces, el Unix original no tenía licencia y el proyecto GNU necesitaba un shell que estaba bajo la GPL, por lo que usaron el bash.

Lo mismo es cierto para BSD4, el padre de todos los BSD. Gracias a la demanda de AT&T, tuvieron que reescribir toda la fuente del Unix original, incluido el shell Bourne.

En la línea tradicional BSD, el shell Bourne se envió hasta 4.3BSD-Reno (pero ya no con Net / 2 y los siguientes 4.4BSD). Por razones de licencia, Kenneth Almquist (a menudo llamado ceniza) lo sustituyó con el shr4-like shr4-like shr4.

De FreeBSDs man sh

Un comando sh, el shell Thompson, apareció en la Versión 1 de AT&T UNIX. Fue reemplazado en la Versión 7 AT&T UNIX por el shell Bourne, que heredó el nombre sh.

Esta versión de sh fue reescrita en 1989 bajo la licencia BSD después del Bourne shell de AT&T System V Release 4 UNIX

Por lo tanto, ambos proyectos se vieron obligados a no usar el shell Bourne y conformarse con un verdadero shell de código abierto.

Raphael Ahrens
fuente
7

Ha habido otros problemas. Bourne Shell usó sbrk () en lugar de malloc () y esto lo hizo no muy portátil.

Después de que Bourne Shell se convirtiera en OpenSource a través de OpenSolaris, creé una versión portátil hafway y luego una versión realmente portátil reemplazando sbrk () por malloc () con la ayuda de Geoff Collyer (la misma persona que ayudó a evitar sbrk () en el Korn Shell).

La razón inicial por la que hice una versión portátil de Bourne Shell es que me gustaba hacer que el Editor de Historia que escribí para mi "bsh" entre 1982 y 1984 también estuviera disponible en Bourne Shell. Mientras tanto, porté la mayoría de las características únicas que escribí para "bsh" al Bourne Shell.

Esto es entre otros:

  • Compila y funciona en casi todas partes, incluido Cygwin (casi 2 veces más rápido que bash)
  • El editor de historia con un buffer de anillo LRU
  • TERMCAP incorporado
  • Alias ​​avanzados (alias persistentes globales, alias locales, ....) y junto con el "dosh" integrado, Bourne Shell es la única implementación similar de Bourne Shell que permite alias parametrizables.
  • Soporte para editar alias complejos en el editor de historial en modo sin procesar.
  • Acceda a los 32 bits del código de salida (2) a través de las variables .sh. *.
  • sincronización automática avanzada con resolución de 6 dígitos
  • pushd / popd / dirs
  • incorporado "encontrar"
  • Tubo de stderr
  • Usando vfork () para un mejor rendimiento.
  • finalmente reparó todos los errores documentados del SVr4 Bourne Shell, por ejemplo, suspender siempre funciona en modo de control de trabajo. ...

La página de manual en línea está en: http://schillix.sourceforge.net/man/man1/bosh.1.html Las fuentes son parte de la caja de herramientas schily en:

https://sourceforge.net/projects/schilytools/files/

Recomiendo usar: http://sourceforge.net/projects/schilytools/files/schily-2015-08-18.tar.bz2 o una versión más nueva.

PD Estoy interesado en comentarios

astuto
fuente
Hola joerg ¿Por qué portarlos al shell Bourne en lugar de un shell que ya había sido POSIXIFICADO como algunos BSD sh o pdksh?
Stéphane Chazelas
La transferencia de Bourne Shell fue un desafío ya que no utiliza stdio. Este fue un desafío similar a tomar la fuente csh original y hacerla compilar reemplazando el printf no estándar escrito en el ensamblador VAX. Pero ya agregué muchas características POSIX más nuevas al Bourne Shell y me gusta quedarme con el Bourne Shell en SchilliX para permitir que arranque con / anr / usr en sistemas de archivos separados, lo que no es posible con el Korn Shell.
schily
También tenga en cuenta que quería verificar que la velocidad de ksh se debe al uso de vfork (). Ahora que he convertido Bourne Shell para usar vfork () es exactamente tan rápido como las versiones recientes de ksh. Esta es una experiencia que solo se obtiene al comenzar con el código fuente original de Bourne Shell.
schily
Está bien, pero hasta que haga que sh POSIX sea conforme, no es probable que atraiga mucho interés. Recuerdo que preguntaste en el grupo ML de Austin sobre las incompatibilidades con POSIX del shell Bourne, ¿es algo en lo que estás trabajando (lo que significaría romper la compatibilidad con el shell Bourne)? También la gente (al menos) considera que la sintaxis sh de POSIX es un progreso sobre el shell Bourne. Si sigue llamando a su shell derivado de Bourne, el shell Bourne puede enviar una impresión incorrecta. ¿Qué tal bimsh (Bourne mejorado (ala vi / vim))?
Stéphane Chazelas
Mi Bourne Shell ya es mejor que ksh en algunos aspectos, por ejemplo, implementando mejores alias, pushd / popd / dirs y soporte de usilización de recursos basado en características modernas de UNIX, en cambio, si lo que hace ksh que todavía está basado en SVr2. Como parece estar interesado y experto en el shell, me gustaría obtener ideas sobre lo que le gustaría ver a continuación en Bourne Shell después de leer: schillix.sourceforge.net/man/man1/bosh.1.html Tenga en cuenta que hasta ahora, tengo todo el código nuevo # ifdef'd y algunas características (como las tuberías stderr) deben activarse a través de set (1).
schily
4

Está vinculado a shells que proporcionan una compatibilidad con el 100% hacia atrás . No pierdes nada de lo que tiene el shell original, pero obtienes más funciones. No hay inconveniente, ¿por qué perderse las nuevas funciones? Esta es la misma razón por la /bin/vique generalmente está vinculada a vim .

JoelFan
fuente
55
La desventaja es que las personas escriben guiones que funcionan en su único sistema, pensando que su guión es compatible cuando no lo es. Una vez arreglé casi un centenar de scripts de shell Gentoo que en realidad requerían bash pero llamaban / bin / sh. Todos se rompieron cuando cambié / bin / sh para que fuera un guión en lugar de bash.
Zan Lynx
3
"sin inconvenientes" - velocidad. por ejemplo, bashes mucho, mucho más lento quedash
strugee
@strugee Si está buscando mejoras en el rango de ms en un shell, probablemente no esté utilizando la herramienta adecuada para el trabajo.
Chris Down
1
@ChrisDown define "mejoras de rango ms"?
Strugee
2
La sintaxis sh POSIX no es totalmente compatible con la sintaxis sh Bourne. Por ejemplo, IFS=,; rm file1,file2,file3eliminaría esos 3 archivos en el shell Bourne. Eso (tonto) característica se eliminó en POSIX sh. Hay docenas de diferencias sutiles que podrían hacer que un script escrito para el shell Bourne funcione de manera diferente con un POSIX sh.
Stéphane Chazelas