¿Por qué bash es el shell por defecto en la mayoría de los sistemas operativos?

37

¿Por qué bash es el shell predeterminado en la mayoría de los sistemas operativos (Ubuntu, Fedora, OSX, etc.)? ¿Por qué muchos usuarios avanzados usan principalmente zsh? Si es así de bueno, ¿por qué no es el valor predeterminado?

Utilizo ambos. No veo la diferencia porque todas mis tareas son simples:)

    
pregunta Talal 20.06.2015 - 21:52

5 respuestas

32

Leí algo sobre esto y la conclusión parece ser que es el shell predeterminado de GNU (utilizado por la mayoría de los basados ​​en Linux) OS), y por lo tanto, simplemente viene empaquetado como parte de GNU, a la vez que tiene 20 años de desarrollo que lo hace estable y completo, es simplemente el mejor todo terreno, satisfaciendo las necesidades de todos los usuarios, excepto los más avanzados.

Para obtener más información, lea ¿Por qué bash es estándar en Linux? (la misma pregunta en Unix y Linux).

Solo para agregar un poco más a esto, hay muchas otras conchas que probar, si estás interesado, aquí hay algunas de esta respuesta :

  
  • Zsh tiene más avanzado   instalaciones interactivas, pero algunas peculiaridades cuando se trata de scripting   (menos ahora que antes en los días). En la primera mitad de la década de 1990 cuando   Linux estaba en su infancia, zsh era prácticamente desconocido.

  •   
  • Ksh era de facto   estándar en unidades comerciales desde mediados de la década de 1980, pero fue   software propietario hasta 2000, entonces no es una opción en Linux. Además, ksh   tenía capacidades de edición de línea de comando inferiores, en comparación con bash.

  •   
  • Pdksh , un clon gratuito de ksh,   habría sido una opción, pero no era conocida y tenía poca   capacidades de edición de línea de comando. (Pdksh ya no es muy activo   proyecto, aunque todavía se usa en algunos BSD, ahora que ATT ksh es   gratis.)

  •   
  • Algunas distribuciones instalan una    ash variante como   %código%. Ash (me refiero a cualquiera de las familias de conchas sueltas   llamada ceniza) está diseñado para ser pequeño y rápido, sin interacción   características (es solo para editar scripts). El renacimiento de la ceniza es   relativamente reciente; en la década de 1990 las variantes existentes carecían de una gran cantidad de   características.

  •   
  • Tcsh era el más avanzado   shell interactivo hasta que llegó zsh, pero es incompatible con sh   y no tan bueno con   scripting .

  •   
    
respondido por el Mark Kirby 20.06.2015 - 22:25
8

La shell Bourne ( sh en el día) de la rama AT & amp; T de Unix fue mejorada y reemplazada por Korn Shell, ksh . ksh también salió de AT & amp; T Bell Labs y no era GPL (la versión actual es Eclipse Public License). El C-shell, csh salió de la versión Berkeley de Unix y tampoco era GPL (licencia BSD) y también usaba sintaxis diferente que sh. El Z-shell, zsh es una mejora en sh pero no en GPL (licencia tipo MIT). Bash fue una mejora en sh, usó la GPL y de GNU. Solo con licencia, Bash probablemente habría sido la opción para un sistema operativo GPL. Particularmente con un shell siendo una parte central de una distribución.

Pero Bash también fue un proyecto de GNU, lo que le da, creo, un desarrollo más activo y contribuciones más sencillas que un producto heredado de Berkeley Unix o AT & amp; T Unix. Un muy buen caso podría ser que zsh es y ha sido un shell mejor que Bash, pero no lo suficiente como para superar su licencia diferente y el estado del proyecto no de GNU.

Cuando aparecieron las distribuciones de Linux y eligieron su shell por defecto (principios y mediados de los 90), no existía github (2008) o incluso SourceForge (1999). En ese momento, creo que los proyectos de GNU tienen una ventaja real sobre los proyectos que no son de GNU para que se noten y atraigan e incluyan nuevos desarrolladores. Por lo tanto, las distribuciones podrían considerar Z-shell como mejor, pero también esperan que Bash reciba un buen soporte y mantenimiento en el futuro, y también se le agregarán más funciones, lo que le permitirá alcanzar hasta zsh.

Ahora que Bash ha tenido años de estado predeterminado, se ha convertido en un estándar de facto, con libros escritos sobre él. Hay un libro que cubre Bash y Z-shell , pero ningún libro que lo cubra exclusivamente, mientras que hay varios que lo hacen para Bash.

Y en este punto, si las distribuciones cambiaran el valor predeterminado para las actualizaciones de un sistema existente, rompería las configuraciones ya que algunos de los archivos de inicialización tienen diferentes nombres (por ejemplo, .bashrc versus .zshrc) y el contenido de los archivos puede tener sintaxis incompatible Por lo tanto, serían muy reacios a hacer eso, dejando nuevas descargas para tener zsh como predeterminado y actualizaciones para tener bash. Dos valores predeterminados diferentes para la misma distribución es algo que probablemente no quieran soportar y los usuarios / empresas tampoco quieran tratar con ellos.

    
respondido por el Scooter 21.06.2015 - 06:28
1

Los lenguajes de shell de Unix son todos feos. Algunos en particular ( csh ), algunos tal vez un poco menos ( ksh ? No lo sé en realidad), pero realmente cuando se trata de aspectos como la legibilidad y la rigidez de los grandes proyectos, ninguno de ellos puede acercarse a ... Lenguajes de uso general diseñados como Python, C # o Haskell. Entonces, cuando quieras algo sólido, nunca elegirás ninguno de los sabores de shell en absoluto.

Los eliges cuando quieres hacer cosas simples rápidamente. Para esto, necesitas:

  • Sintaxis concisa y suficiente consistencia para que puedas memorizarla (es difícil buscar operadores taquigráficos). Importa mucho si tu caparazón está instalado en todas partes, porque en realidad preferirías no memorizar más de uno de estos monstruos kludge.
  • Buenas características interactivas, por lo que puedes hackear directamente la terminal y hacer que funcionen cosas sin tener que cambiar entre múltiples archivos de script.
  • La capacidad de capturar cualquier fragmento de script desde cualquier lugar y hacer que funcione. La compatibilidad sh es una gran ventaja aquí, y una vez más, cuanto más popular, mejor.

Como puede ver, la popularidad es un punto más importante en estos lenguajes de shell que en los lenguajes de propósito general. Por lo tanto, incluso si ksh es un poco "mejor" como lenguaje en sí mismo, no hay mucha ventaja en su uso si bash es un poco más popular (lo que era, en el sector relevante, ya que se eligió por primera vez como el valor predeterminado para GNU).

Las personas que hacen el cambio son deliberadas y tienen experiencia suficiente para manejar fácilmente el cambio a su caparazón favorita. OTOH, un novato que se ve obligado a trabajar con un shell menos popular, se confundirá rápidamente si le piden algo a Internet y no funciona. Por lo tanto, cualquier distribución que no solo esté dirigida a los veteranos de Unix implica un gran riesgo si hace cualquier cosa menos bash el estándar, un paso del que se beneficiarían relativamente pocas personas (y solo un poco).

    
respondido por el leftaroundabout 21.06.2015 - 01:49
1
  1. Estaba allí cuando fue necesario
  2. Tiene suficientes efectos visuales que los usuarios principiantes pueden pasar una semana personalizando su mensaje.
  3. Los casos de uso común son lo suficientemente buenos (el más común es iniciar un solo comando)
  4. Donde no es lo suficientemente bueno, python y lua pueden tomar el relevo.
  5. perl hace un shell interactivo terrible
  6. aunque en teoría fish, ksh o zsh pueden ser una mejor coraza, no hay suficiente mejora como para molestarme cuando la perl funciona tan bien o la portabilidad es un problema, así que me estoy enfocando en la orientación de todos modos.
respondido por el hildred 21.06.2015 - 06:06
0

"Masa crítica" es la respuesta principal, IMO. Bash no es solo para el trabajo de línea de comandos, es para guiones y hay una gran cantidad de scripts Bash por ahí. No importa cuán mejor sea ahora una alternativa para la interacción, la necesidad de poder simplemente "conectar y usar" esas secuencias de comandos supera esas ventajas. Como tal, el único caparazón que puede destronar a Bash de forma realista es uno que es completamente compatible con versiones anteriores y el candidato más probable para eso es ... la próxima versión de Bash.

    
respondido por el Nagora 21.06.2015 - 00:24

Lea otras preguntas en las etiquetas