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

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

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

Leí un poco sobre esto y la conclusión parece ser que es el shell predeterminado de GNU (utilizado por la mayoría de los sistemas operativos basados ​​en Linux) y, por lo tanto, simplemente viene empaquetado como parte de GNU, mientras que también tiene 20 años de desarrollo detrás, lo que lo hace estable y bien redondeado, es simplemente el mejor todoterreno, que satisface 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 muchos otros shells para probar, si está interesado, aquí hay algunos de esta respuesta :

• Zsh tiene instalaciones interactivas más avanzadas, pero algunas peculiaridades cuando se trata de secuencias de comandos (menos ahora que en el pasado). A principios y mediados de la década de 1990, cuando Linux estaba en su infancia, zsh era prácticamente desconocido.

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

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

• Algunas distribuciones instalan una variante de ceniza como /bin/sh. Ash (con lo que me refiero a cualquiera de la familia de conchas sueltas llamada ash) está diseñado para ser pequeño y rápido, sin características interactivas (es solo para editar guiones). El avivamiento de las cenizas es relativamente reciente; En la década de 1990, las variantes existentes carecían de muchas características.

• Tcsh fue el shell interactivo más avanzado hasta que apareció zsh, pero es incompatible con sh y no es tan bueno con los scripts .

El Bourne Shell ( sh back in the day) de la rama AT&T de Unix fue mejorado y reemplazado por el Korn Shell, ksh . ksh también salió de AT&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 una sintaxis diferente a la sh. El Z-shell, zsh es una mejora en sh pero no 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 caparazón que es una parte central de una distribución.

Pero Bash también fue un proyecto GNU, lo que le dio, creo, un desarrollo más activo y facilitó las contribuciones que un producto heredado de Berkeley Unix o AT&T Unix. Un 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 que no es GNU.

Cuando las distribuciones de Linux aparecieron por primera vez y eligieron su shell predeterminado (desde principios hasta mediados de los 90), no había github (2008) o incluso un SourceForge (1999). En ese momento, creo que los proyectos GNU tenían una ventaja real sobre los proyectos que no son GNU para hacerse notar y dibujar e incluir nuevos desarrolladores. Por lo tanto, las distribuciones podrían considerar a Z-shell como mejor, pero también esperar que Bash obtenga un buen soporte y mantenimiento en el futuro, y también tener más características agregadas, lo que le permitirá alcanzar zsh.

Ahora que Bash ha tenido años de estado predeterminado, se ha convertido en un estándar de facto, con libros escritos al respecto. Hay un libro que cubre tanto Bash como Z-shell , pero no hay un 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, se romperían las configuraciones ya que algunos de los archivos de inicialización tienen nombres diferentes (por ejemplo .bashrc versus .zshrc) y el contenido de los archivos puede tener una sintaxis incompatible. Por lo tanto, serían muy reacios a hacer eso, dejando que las nuevas descargas tengan zsh como predeterminado y las actualizaciones tengan bash. Dos valores predeterminados diferentes para la misma distribución es algo que probablemente no quieren tener que apoyar y los usuarios / empresas tampoco quieren tratar.

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 para grandes proyectos, ninguno de ellos puede acercarse a lenguajes de propósito general bien diseñados como Python, C # o Haskell. Entonces, cuando quieras algo sólido, nunca elegirás ninguno de los sabores de concha.

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

• Sintaxis concisa y suficiente consistencia para que pueda memorizarla (es difícil buscar operadores abreviados). Importa mucho si tu shell está instalado en todas partes, porque realmente prefieres no memorizar más de uno de estos monstruos kludge.
• Buenas funciones interactivas, para que pueda hackear directamente la terminal y hacer que las cosas funcionen sin tener que cambiar entre múltiples archivos de script.
• La capacidad de tomar cualquier fragmento de script desde cualquier lugar y hacer que funcione. shla compatibilidad 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 uso general. Por lo tanto, incluso si kshes un poco "mejor" como lenguaje en sí mismo, no hay realmente muchas ventajas en usarlo si bashes un poco más popular (que era, en el sector relevante, ya que se eligió por primera vez como predeterminado para GNU).

Las personas que hacen el cambio son deliberadas al respecto y tienen la experiencia suficiente para manejar fácilmente el cambio a su caparazón favorito. 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 veteranos de Unix toma bastante riesgo si hace algo más que bashel estándar, un paso del que relativamente pocas personas se beneficiarían (y solo un poco).

1. Estaba allí cuando era necesario.
2. Tiene suficientes ojos dulces que los usuarios principiantes pueden pasar una semana personalizando su mensaje.
3. Los casos de uso comunes son lo suficientemente buenos (el más común es iniciar un solo comando)
4. Donde no es lo suficientemente bueno, Perl, Python y Lua pueden tomar el relevo.
5. Perl hace un terrible shell interactivo
6. Aunque en teoría fish, ksh o zsh pueden ser un mejor caparazón, no hay una mejora suficiente para que me moleste cuando Perl funciona tan bien o la portabilidad es un problema, por lo que estoy apuntando a dash de todos modos.

"Masa crítica" es la respuesta principal, OMI. Bash no es solo para el trabajo de línea de comandos, es para secuencias de comandos y hay una gran cantidad de secuencias de comandos Bash. No importa cuán mejor sea ahora una alternativa para la interacción, la necesidad de poder simplemente "enchufar y reproducir" esos scripts supera esas ventajas. Como tal, el único caparazón que puede eliminar a Bash de manera realista ahora 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.