¿Hay alguna razón para usar bash sobre zsh? [cerrado]

33

Tengo curiosidad acerca de por qué uno querría ejecutar bash en lugar de zsh. Quiero decir que zsh es totalmente compatible con bash. No me malinterpreten: no me gusta bash ni nada. Solo quiero saber si hay alguna ventaja en usarlo sobre zsh.

Entonces, ¿qué razón hay para usar bash sobre zsh?

Jason Baker
fuente
2
Solo quería señalar que ZSH no es totalmente compatible con BASH. En ZSH, la indexación de matriz comienza en 1 - en BASH, la indexación de matriz comienza en 0. También hay otras diferencias, pero quería señalar esta.
Charles Addis

Respuestas:

29

Se me ocurren dos razones:

Primero, está disponible prácticamente en todas partes. Tengo varios sistemas Linux (CentOS 4.x en este caso) que no tienen instalado zsh. Del mismo modo, tengo que tocar sistemas antiguos como Solaris 2.6 y versiones posteriores, HP-UX 10 y versiones posteriores, y versiones similares de AIX. Por lo tanto, tengo que usar bash en estas computadoras, lo cual hago porque toco docenas, si no cientos, de computadoras individuales en el transcurso de un mes, y para obtener consistencia en su interfaz, termina atascado usando el valores predeterminados

Segundo: está disponible prácticamente en todas partes. Esto significa que puedo escribir un script de shell bash y estar 99% seguro de que funcionará cuando se transfiera a otro lugar.

Sí, estas razones son superficialmente las mismas, pero el razonamiento detrás de ellas es diferente.

David Mackintosh
fuente
2
Recuerdo que tenía ksh88 / ksh93 en HPUX, nunca tuvimos acceso para instalar bash.
Zlemini
24

Bash generalmente viene con todos los sistemas, zsh no. Me encanta zsh, pero debido a esto, uso zsh para uso interactivo, pero Bash para todos mis scripts .

Creo que esto hace que todo sea más simple, ya que incluso cuando compro lo que sea compatible con bash (¿selecciona SH_WORD_SPLIT?), Todavía me encuentro con diferencias sutiles.

Kyle Brandt
fuente
3
¿Eso sería todos los sistemas GNU / Linux que quieres decir?
andol
2
Bueno, he encontrado que viene con OS / X y bsd, no tengo mucha experiencia con otros * nix's, ¿no suelen tener bash (versiones recientes)?
Kyle Brandt
1
Las versiones anteriores de Solaris no incluían bash; Por lo general, tenía que depender de que Bourne fuera el shell para las secuencias de comandos. Este no ha sido el caso por un tiempo, pero aún puede encontrarlo en algunas grandes empresas.
user5336
3
Debe haber diferentes BSD: s entonces. Al menos en OpenBSD y en FreeBSD debe instalar bash por separado de los puertos / paquetes.
andol
andol: Esos son los que solía usar ... Debo recordar incorrectamente, o lo hice y simplemente no recuerdo.
Kyle Brandt
13

zsh no es totalmente compatible con bash. Hay una variedad de diferencias. El nuevo zsh es más compatible con bash (= ~ soportado, exec ahora tiene las opciones de bandera adicionales, etc.) pero la compatibilidad total no es un objetivo, ni siquiera bajo "emular".

Por ejemplo, la subcadena bash es $ {foo: offset: len} pero en zsh es $ foo [inicio, final] y ese es solo un ejemplo simple.

zsh es un shell influenciado por tcsh y ksh que hace muchas cosas a su manera; La compatibilidad POSIX no es explícitamente un objetivo, pero los desarrolladores responden a los parches que agregan opciones / emulan el comportamiento que acerca las cosas a POSIX. Pero cuando empiezas a meterte realmente en el poder del shell, comienzas a crear scripts de solo escritura, más aún que bash.

bash es POSIX sh + ksh + pedanticismo, con algunas características ahora copiadas de zsh. También tiene scripts de solo escritura, pero debido a que tiene operadores menos potentes, terminas sin usar la concisión de zsh y las cosas podrían ser más legibles (excepto por todas las citas para evitar la división de espacios en blanco, la estúpida $ ksh-style $ array significa primero) -elemento-de-matriz, no todos-elementos-de-matriz, etc., etc.

Escribir scripts que aprovechen al máximo el poder de cualquiera de los shell no es prudente, a menos que se encuentre en un entorno restringido (por ejemplo, escribir scripts de rc del sistema, donde algunos FS pueden no estar montados, etc.). Como ideal, use Perl / Python / Ruby / lo que sea para algo lo suficientemente grande como para que necesite la expresividad no en Bourne sh, si desea que otros puedan mantenerla. Guarde las cosas del shell para cosas relacionadas con el shell interactivo (programación de finalización de pestañas, etc.).

No usaría bash sobre zsh. Usaría bare sh sobre zsh para scripts simples, o cambiaría a un lenguaje donde las matrices asociativas tengan operadores decentes (a diferencia de zsh, donde están, nuevamente, 'concisos'). Yo podría cambiar un script sh para fiesta si necesito que una característica poco para extender una escritura probada de trabajo existente y no tienen tiempo para volver a escribir ahora.

Phil P
fuente
66
nb: $ {foo: offset: len} ahora es compatible con zsh, por compatibilidad.
Phil P
6

Mi consejo: si buscas una portabilidad absoluta, escribe usando las reglas de shell Bourne, ni siquiera te molestes con las extensiones de shell Korn. Como se mencionó, hay algunas "cajas grandes" más antiguas que no tienen caparazones de GNU.

Bash ya hace "demasiado". Tengo un amigo en el trabajo que prefiere zsh, pero no sé qué hace exactamente.

De todos modos, escriba para el shell Bourne (o "bourne again"), o alternativamente, si está haciendo un script personalizado para un pequeño número de cuadros específicos, omita el "infierno del shell" por completo, y simplemente escriba usando perl o python (o lo que sea su intérprete favorito instalado localmente es).

Roboprog
fuente
5

Además de la razón de portabilidad dada anteriormente, otra podría ser que bash todavía está agregando características.

Por ejemplo, bash v4.x + introducido:

  • engrosamiento recursivo:

    rm -f ** / *. log

  • autocd:

    Escriba "/ tmp" en lugar de "cd / tmp"

cabalgada
fuente
2
¿De qué manera bash copia características de zsh una razón para usar bash?
qqx
5

Por cierto, aquí te han dicho muchas veces que bash se encuentra prácticamente en todas partes, así que úsalo para escribir scripts portátiles, lo cual es falso.

Disparates. Si sabe que cada sistema que le interesa tiene BASH, entonces es una declaración perfectamente razonable. BASH tiene muchas características útiles que no se pueden emular razonablemente en POSIX sh. El uso frívolo de las funciones que no son POSIX no es una gran idea, pero usarlas cuando realmente las necesita está bien.

La portabilidad no es un absoluto. Es discutible lo lejos que necesita llevarlo, como cualquier otra cosa. Por ejemplo, Fedora usa comandos de shell para construir paquetes RPM y las pautas de empaquetado de Fedora establecen que dado que todos los paquetes deben construirse de forma nativa en Fedora, está bien usar todas las características de BASH. Aunque teóricamente otras distribuciones sin BASH pueden querer reutilizar sus RPM de origen, tomaron una decisión sobre la portabilidad basada en la practicidad en lugar de su mantra "SIEMPRE UZE POSIX !! 1".

ZSH no se ha convertido en un shell predeterminado, simplemente porque es un desorden extenso de ideas a medias.

Craig
fuente
2
¿Puede explicar qué características o ideas en zsh encuentra que están medio cocidas y por qué?
Funroll
2

Por cierto, aquí te han dicho muchas veces que bashse encuentra prácticamente en todas partes, así que úsalo para escribir scripts portátiles, lo cual es falso .

La forma correcta de escribir scripts portátiles de Unix es usar sh, que se encuentra en todos los sistemas * nix .

Cualquier otro shell, excepto shes solo una herramienta interactiva diaria tuya.

Cuando se trata de bashvs zsh- bashse incluye en más *nixesde zsh, así que aquí vienen las desventajas de instalar software adicional en el sistema: debe mantenerlo. Algunas personas adoran las "características geniales" de zsh, por lo que les gusta pagar ese precio, otras no.

Samat
fuente
2
Muchas implementaciones modernas de sh son solo enlaces a bash.
user9517 es compatible con GoFundMonica el
2
@Iain Ubuntu usa el guión de forma predeterminada, e incluso si shes bash, habilita el modo de compatibilidad cuando se ejecuta como sh.
mgorven
2

Otro punto:

Muchos programas proporcionan una finalización de bash genial por defecto. Para mí es la razón para no cambiar.

[agregado en julio de 2013] Bueno, después de algunos años de usar zsh desde el comentario anterior, tengo que decir que la finalización de pestañas (incluso una, sin modificaciones de tercer padre) es brillante y parece que va mucho más allá de lo que ofrece bash . :).

Wojciech Kaczmarek
fuente
3
Creo que funciona con ZSH, así, con la implementación del tabulador en ZSH, recibo muchos argumentos específicos del programa ...
Kyle Brandt
Interesante. ¿Estás diciendo que los archivos de finalización de bash funcionan con zsh, o solo algunos programas tienen su material de finalización específico de zsh? Todavía hay algún diseño estándar de archivos de finalización de bash que zsh puede o no considerar automáticamente. ¿Has ajustado tu configuración de zsh para que funcione?
Wojciech Kaczmarek
@Wojciech Kaczmarek: Creo que quieres el 19.3 de lo siguiente: zsh.sourceforge.net/Doc/Release/zsh_19.html . Honestamente, nunca me tomé el tiempo para entenderlo realmente, simplemente arranqué un .zshrc que encontré en línea :-) Pero completará los argumentos de la línea de comandos de programas como apt, grep, etc ...
Kyle Brandt
55
La finalización de pestañas de bash es muy similar al antiguo sistema de finalización de pestañas de zsh. Esta es una de las ideas copiadas de zsh a bash (hay otras copiadas de bash a zsh). Puede usar scripts de finalización escritos para bash en zsh, ejecutando "bashcompinit" y luego usando los comandos "complete" y / o "compgen" dentro de zsh; esto es posible porque la funcionalidad de bash es un subconjunto de lo disponible en zsh y entonces puede ser emulado. Entonces, no hay razón para cambiar a bash porque un comando se envía con una finalización de bash.
Phil P