¿Bash o KornShell (ksh)?[cerrado]

Question

No soy nuevo en *nix, sin embargo últimamente he pasado mucho tiempo siguiendo el mensaje.Mi pregunta es ¿cuáles son las ventajas de usar KornShell (ksh) o Bash Shell?¿Cuáles son los riesgos de utilizar uno sobre el otro?

Buscando comprender desde la perspectiva de un usuario, en lugar de simplemente escribir un script.

Answer 1

Intento.

Las diversas implementaciones de UNIX y Linux tienen varias implementaciones de ksh a nivel fuente diferente, algunas de las cuales son ksh real, algunas son implementaciones de pdksh y algunas son solo enlaces simbólicos a algún otro shell que tiene una personalidad "ksh".Esto puede generar diferencias extrañas en el comportamiento de ejecución.

Al menos con bash puedes estar seguro de que es una base de código única, y lo único de lo que debes preocuparte es qué versión (generalmente mínima) de bash está instalada.Habiendo realizado muchas secuencias de comandos en casi todos los UNIX modernos (y no tan modernos), según mi experiencia, la programación para bash es más confiable y consistente.

Answer 2

La diferencia entre Kornshell y Bash es mínima.Hay ciertas ventajas que uno tiene sobre el otro, pero las diferencias son mínimas:

• BASH es mucho más fácil configurar un mensaje que muestre el directorio actual.Hacer lo mismo en Kornshell es una tontería.
• Kornshell tiene matrices asociativas y BASH no.Ahora, la última vez que usé matrices asociativas fue...Déjame pensar...Nunca.
• Kornshell maneja un poco mejor la sintaxis de bucle.Generalmente puedes establecer un valor en un bucle Kornshell y tenerlo disponible después del bucle.
• Bash maneja la obtención de códigos de salida de las tuberías de una manera más limpia.
• Kornshell tiene la print comando que es mucho mejor que el echo dominio.
• Bash tiene terminaciones de pestañas.En versiones anteriores
• Kornshell tiene la r comando de historial que me permite volver a ejecutar rápidamente comandos más antiguos.
• Kornshell tiene la sintaxis cd old new que reemplaza old con new en su directorio y CD allí.Es conveniente cuando estás en un directorio llamado /foo/bar/barfoo/one/bar/bar/foo/bar y necesitas cd para /foo/bar/barfoo/two/bar/bar/foo/bar En Kornshell, simplemente puedes hacer cd one two y terminar con esto.En BASH, tendrías que cd ../../../../../two/bar/bar/foo/bar.

Soy un viejo tipo Kornshell porque aprendí Unix en la década de 1990, y ese era el shell elegido en aquel entonces.Puedo usar Bash, pero a veces me frustra porque por costumbre uso alguna característica menor que tiene Kornshell y que BASH no tiene y no funciona.Entonces, siempre que sea posible, configuro Kornshell como predeterminado.

Sin embargo, te voy a decir que aprendas BASH.Bash ahora está implementado en la mayoría de los sistemas Unix, así como en Linux, y simplemente hay más recursos disponibles para aprender BASH y obtener ayuda que Kornshell.Si necesita hacer algo exótico en BASH, puede ir a Stackoverflow, publicar su pregunta y obtendrá una docena de respuestas en unos minutos, ¡y algunas de ellas incluso serán correctas!

Si tienes una pregunta de Kornshell y la publicas en Stackoverflow, tendrás que esperar a que algún viejo hacker como yo se despierte de su siesta antes de recibir una respuesta.Y olvídese de recibir respuesta si ese día sirven pudín en el asilo de ancianos.

BASH es simplemente el shell preferido ahora, por lo que si tienes que aprender algo, también puedes optar por lo que es popular.

Answer 3

Soy un veterano del kornshell, así que sepan que hablo desde esa perspectiva.

Sin embargo, me he sentido cómodo con Bourne Shell, ksh88 y ksh93, y en general sé qué funciones son compatibles con cada una.(Debería omitir ksh88 aquí, ya que ya no se distribuye ampliamente).

Para uso interactivo, tome lo que se adapte a sus necesidades.Experimento.Me gusta poder usar el mismo shell para uso interactivo y para programación.

Pasé de ksh88 en SVR2 a tcsh, a ksh88sun (que agregó un importante soporte de internacionalización) y ksh93.Probé Bash y lo odié porque aplanó mi historia.Entonces descubrí shopt -s lithist y todo estuvo bien.(El lithist La opción asegura que las nuevas líneas se conserven en su historial de comando.)

Para la programación de shell, recomendaría seriamente ksh93 si desea un lenguaje de programación consistente, buena conformidad con POSIX y buen rendimiento, ya que muchos comandos comunes de Unix pueden estar disponibles como funciones integradas.

Si desea portabilidad, utilice al menos ambos.Y asegúrese de tener un buen conjunto de pruebas.

Hay muchas diferencias sutiles entre los caparazones.Considere, por ejemplo, leer desde una tubería:

b=42 && echo one two three four |
    read a b junk && echo $b

Esto producirá diferentes resultados en diferentes shells.El korn-shell recorre las tuberías de atrás hacia adelante;el último elemento de la tubería se ejecuta en el proceso actual.Bash no admitió este útil comportamiento hasta la versión 4.x, e incluso entonces, no es el predeterminado.

Otro ejemplo que ilustra la coherencia:El echo comando en sí, que quedó obsoleto por la división entre BSD y SYSV Unix, y cada uno introdujo su propia convención para no imprimir nuevas líneas (y otros comportamientos).El resultado de esto todavía se puede ver en muchos scripts de 'configuración'.

Ksh adoptó un enfoque radical al respecto e introdujo la print comando, que en realidad admite ambos métodos (el -n opción de BSD, y el final \c carácter especial de SYSV)

Sin embargo, para una programación seria de sistemas, recomendaría algo más que un shell, como python, perl.O vaya un paso más allá y utilice una plataforma como Puppet, que le permite observar y corregir el estado de grupos completos de sistemas, con una buena auditoría.

La programación de Shell es como nadar en aguas desconocidas, o algo peor.

Programar en cualquier lenguaje requiere estar familiarizado con su sintaxis, sus interfaces y su comportamiento.La programación Shell no es diferente.

Answer 4

No tengo experiencia con ksh, pero he usado bash y zsh.Prefiero zsh a bash debido a su compatibilidad con la agrupación de archivos muy potente, modificadores de expansión variable y finalización de pestañas más rápida.

Aquí hay una introducción rápida: http://friedcpu.wordpress.com/2007/07/24/zsh-the-last-shell-youll-ever-need/

Answer 5

Esta es una especie de batalla entre Unix y Linux.La mayoría, si no todas, las distribuciones de Linux tienen bash instalado y ksh opcional.La mayoría de los sistemas Unix, como Solaris, AIX y HPUX, tienen ksh por defecto.

Personalmente siempre uso ksh, me encanta la finalización de vi y prácticamente uso Solaris para todo.

Answer 6

Para los scripts, siempre uso ksh porque suaviza trampas.

pero encuentro intento Más cómodo para uso interactivo.para mi el emacs Las combinaciones de teclas y la finalización de pestañas son los principales beneficios.Pero eso es más que nada cuestión de costumbre, no de ningún problema técnico. ksh.

Answer 7

@foxxtrot

En realidad, el shell estándar es el shell Bourne (sh). /bin/sh en Linux es en realidad bash, pero si busca scripts multiplataforma, es mejor que se ciña a las características del shell Bourne original o lo escriba en algo como perl.

Answer 8

Mi respuesta sería "elige uno y aprende a usarlo".Ambos son caparazones decentes;bash probablemente tenga más detalles, pero ambos tienen las características básicas que querrás.bash está disponible más universalmente en estos días.Si usas Linux todo el tiempo, quédate con él.

Si está programando, tratar de ceñirse a 'sh' simple para la portabilidad es una buena práctica, pero con bash disponible tan ampliamente en estos días, ese consejo probablemente esté un poco pasado de moda.

Aprenda a utilizar la finalización y su historial de shell;Lea la página de manual de vez en cuando e intente aprender algunas cosas nuevas.

Answer 9

Por un lado, bash tiene finalización con pestañas.Esto por sí solo es suficiente para hacerme preferirlo a ksh.

concha Z tiene una buena combinación de las características únicas de ksh con las cosas interesantes que ofrece bash, además de muchas más cosas además.

Answer 10

Disponible en la mayoría de los sistemas UNIX, ksh cumple con los estándares, está claramente diseñado y es completo.Creo que los libros que ayudan en ksh son suficientes y claros, especialmente el libro de O'Reilly.Bash es una masa.Lo mantengo como shell de inicio de sesión raíz para Linux solo en casa.

Para uso interactivo, prefiero zsh en Linux/UNIX.Ejecuto scripts en zsh, pero probaré la mayoría de mis scripts, aunque funciona en AIX ksh.

Answer 11

Bash es el punto de referencia, pero eso se debe principalmente a que puedes estar razonablemente seguro de que está instalado en todos los *nix que existen.Si planea distribuir los scripts, use Bash.

Desafortunadamente, no puedo abordar las diferencias de programación reales entre los shells.

Answer 12

Intento es el estándar para Linux.
Mi experiencia es que es más fácil encontrar ayuda para bash que para ksh o csh.