He usado bash, csh y tcsh. Pero pregunté this question, y Jonathan me informó que no se debe confiar en csh. Entonces, ¿qué shell de Linux es bueno para el desarrollo? ¿y por qué?¿Qué shell de Linux debería usar?
Normalmente me quedo con bash, porque es más amigable que straight-up sh, y es el predeterminado en todas las distribuciones que he usado semi-regularmente (SuSE, RHEL, Ubuntu, Slackware).
Si está planeando escribir scripts de shell portátiles, asegúrese de que todos se ejecuten en real sh.
¿Qué quieres decir con real sh? Hay muchos shells, incluido bash, que pretenden implementar posix sh con extensiones, y correr en todos ellos es tan bueno como se puede obtener. Pero incluso si te apegas a posix sh, ¿estás usando algún otro programa que no sea estándar? –
"Real sh" significa exactamente eso: el verdadero Bourne Shell, como/bin/sh en una máquina FreeBSD. Ubuntu tuvo todo tipo de problemas cuando cambiaron de usar bash a dash como su/bin/sh, porque los scripters sin saberlo incluyeron bashisms que fallaron en una implementación más compatible. –
El Bourne Shell real no era compatible con Posix, por lo que no debería instalarse como/bin/sh en ningún Unix moderno. –
El shell más común, de lejos, en Linux es bash. A menos que tenga una buena razón para usar una alternativa, le sugiero que se quede con bash, o con el shell utilizado más comúnmente por su equipo de proyecto (o con la mayoría de los scripts de shell con los que tiene que trabajar).
El único otro contendiente muy común es el dash, que cada vez es más utilizado por el proyecto Ubuntu.
Esto realmente es preferencia personal, bueno, excepto por csh.
Bash. Es estándar.
Simplemente no utilice Korn Shell (ksh).
A menos que tenga una escritura perfecta y nunca tenga que utilizar la tecla de retroceso.
¿Por qué? Nunca he tenido problemas con el uso de la tecla de retroceso en el shell Korn. –
Es cierto, más o menos, pero solo si su sistema está configurado incorrectamente. Si su terminal genera un DEL (0x7f) para el retroceso pero usted tiene el borrado completo configurado en^H, entonces ksh no retrocederá correctamente. bash lo hará de todos modos porque siempre reconoce DEL como retroceso en el que esté configurado el borrado stty. –
OK ... eso tiene algún sentido. Nunca me he dado cuenta del problema, pero probablemente porque rara vez he trabajado en un teclado que genera DEL. –
Me gusta ksh en realidad. Es un poco más consistente que bash porque no intenta soportar ningún constructo csh. tcsh, en mi experiencia, es menos compatible con otras conchas, y lo evito. Intento escribir scripts en sh, pero ksh tiene algunas características interesantes, como exportar y establecer una variable en una línea. Trato de mantener la compatibilidad con bash también, ya que tiene todas las funciones y es común. Para escribir scripts de shell portátiles, que es más importante que seleccionar el "mejor" shell, puede consultar este libro.
portátil Programación Shell: una amplia colección de ejemplos de Bourne Shell (HP Professional Series) por Bruce Blinn (Paperback - 29 de octubre 1995) amazon.com
prefiero zsh.
La rellenar la ficha solo vale la pena:
Disculpe mi ignorancia, pero ¿cómo enumera los interruptores de un ejecutable? ¿Esto solo funciona para programas de uso común como ls, ps, .. o para cualquier programa dado? –
¿Me imagino que analiza las páginas man? No puedo decirlo con seguridad, aunque no uso el zsh aunque podría echar un vistazo a este endoso. – Tarrant
Podría ejecutar el nombre de programa --help en el fondo. – Joshua
utilizo pdksh todo el tiempo sin tener nada cerca de mecanografía perfecto (tal vez tenga que corregir la termcap?).
ksh es el estándar, csh es un estándar y bash es "estándar", pero solo en Linux. Es mejor apuntar a ksh.
Dado que creo que soy la persona que sugirió que use algo distinto a C Shell, quizás debería calificar mis comentarios ligeramente, y luego apoyar a aquellos que dijeron 'bash on Linux, Korn shell en otras plataformas (a menos que bash esté instalado allí también) '.
Más bien como editores (prefieres vim o emacs), la elección del caparazón es en parte una cuestión de familiaridad y, en parte, una cuestión de preferencia. Hay muchos a los que les gusta C shell, aunque creo que es menos fácil de programar que Bourne shell y derivados. Lo que tengo en mi .cshrc es, de hecho, equivalente a exec /bin/ksh (no es idéntico porque quiero ejecutar un shell de inicio de sesión - uno que lea el perfil, etc.), pero no condenaría a nadie por usar C shell o un derivado si se trata de una decisión informada.
Si decide usar algo que no sea C shell, está básicamente en el campo de shell Bourne, para el cual el estándar POSIX especifica más o menos el comportamiento esperado y luego los diferentes shells, es decir, las conchas Bourne, Korn o Born Again - agregue (o, en el caso del shell Bourne clásico, reste) algunas características. Si su código alguna vez necesita moverse de Linux a HP-UX, Solaris o AIX (el trío sobreviviente del clásico AT & variantes de Unix derivadas de T), entonces debería asegurarse de escribir sus scripts de shell en el clásico shell de Bourne. aunque el shell Korn también es bastante seguro. Sin embargo, tenga en cuenta que en Linux puede escribir #!/bin/sh y obtener Bash, en las otras plataformas obtendrá shell Bourne.
Cambio entre el shell Korn y Bash sin mayores problemas, y rara vez con problemas menores. Tiendo a estar lejos de esos rincones de cualquiera de los dos idiomas que no están bien definidos, lo que tiende a significar "definido en ambos". Otro problema para los que usan Linux es que las herramientas GNU tienen más opciones que las versiones clásicas de Unix, y puede perder la portabilidad no debido a las construcciones de programación del shell que utiliza sino por las opciones de comando que utiliza. La experiencia y el acceso fácil a las páginas de manual de otros sistemas ayudan enormemente.
Para interactividad, use Zsh. Durante un tiempo fui el responsable del mantenimiento del puerto FreeBSD de los scripts de finalización de pestañas de Bash, pero lo abandoné tan pronto como probé Zsh por primera vez. Puede hacer todo lo que Bash puede hacer, pero con más facilidad y elegancia. También tiene la agradable propiedad de tener pulsaciones de teclado extremadamente parecidas a las de Bash, por lo que si estás en un sistema sin Zsh, podrás arreglárselas (incluso si no se "siente" tan bien).
Para crear scripts, use Bourne Shell (sh). Es el lenguaje de scripting estándar POSIX y sus scripts están garantizados para funcionar en todas partes. Bash, Zsh y otras conchas tienen buenas extensiones que te perderás, pero que te atan a una configuración específica. Ignore ese consejo para las secuencias de comandos de uso personal que está seguro de que nunca ejecutará en otro lugar, pero recuerde que es una verdadera solución de compromiso que debe tener en cuenta.
Pero en resumen, Zsh. No conozco a nadie que lo haya probado que no haya cambiado de forma inmediata y permanente. Es realmente así de bueno.
"Durante un tiempo fui el responsable del mantenimiento del puerto de FreeBSD de las secuencias de comandos de finalización de pestañas de Bash, pero lo abandoné tan pronto como probé Zsh por primera vez." Eso es, eh ... contar. Sigo pensando en pasar más tiempo con zsh, pero tengo suficiente configuración personalizada Bash que necesitaría pasar algún tiempo reescribiéndolo para la conformidad con zsh. –
"Puede hacer todo lo que Bash puede hacer" Muestre cómo lo hace (reemplace \ n con una nueva línea real): bash -c 'shopt -s expand_aliases 2>/dev/null; alias eecho = echo; \ neecho foo' –
¿Cuál es el objetivo de eso? –
El problema con csh es que es una mierda para scripting, como se explica here. No hay una razón real por la cual no deba usarlo como un shell interactivo, pero la mayoría de las personas lo encuentran confuso al tener que aprender dos shells diferentes y no poder probar partes de sus scripts en la línea de comando, así que es más fácil usar el lo mismo para todo.
Los candidatos obvios para un shell interactivo son bash, dash, zsh y {pd,} ksh. Todos estos implementan el estándar de shell posix, con algunas extensiones menores. Elige lo que quieras para el uso interactivo, yo tendería a ir con bash solo porque es el estándar en Linux, pero todos tienen sus méritos y zsh en particular parece popular.
Si está escribiendo una secuencia de comandos que pretende ser portátil, use #!/Bin/sh, y asegúrese de utilizar la sintaxis estándar de shell posix. Si funciona tanto en bash como en ksh, probablemente sea estándar. Hay algunas versiones antiguas de Unix que tienen un bin/sh no estándar, pero no me molestaría con eso a menos que sepas que tienes que hacerlo. Más de un problema para la portabilidad son todas las herramientas de línea de comandos que llamas desde tu script.
Merece la pena leer el "documento csh considerado dañino", pero creo que la gente también debería leer "Diez razones principales para no usar el shell C" en http://www.grymoire.com/Unix/CshTop10.txt, que hace una mucho mejor caso sobre los problemas de usar csh o tcsh para scripting. También agregaría otro defecto de csh: sin funciones de shell, por lo que los scripts de csh son un espagueti de pequeños scripts que se abastecen entre sí. ¡Tanto por modelarse en C! En cualquier caso, a excepción de los pequeños scripts desechables, para los que utilizo bash, prefiero escribir scripts en Python. –
No soy gran usuario de Ruby, pero se ve interesante http://rush.heroku.com/
Fish (friendly intérprete interactivo) es una buena alternativa a la mayor parte de las otras conchas. Tiene una sintaxis consistente, una buena terminación de pestañas y resaltado de sintaxis, es fácil de usar y de recuperar (especialmente si no tiene hábitos de otras shells), y tiene una excelente ayuda en el tiempo de ejecución.
Lo malo es que está desarrollado erráticamente, tiene una base de usuarios pequeña (pero útil) y es muy diferente a otras conchas. La compatibilidad con versiones anteriores de shell modismos no era una prioridad.
En muchos casos, esto es bueno ... muchas de las conchas estándar tienen formas realmente estúpidas de hacer las cosas, simplemente porque siempre se ha hecho de esa manera. "do/done", "case/esac", "if/fi"? Esta es la locura que los peces eliminan.
Merece la pena echarle un vistazo.
Hay muchos pequeños pequeños cambios que te hacen más productivo con él. La finalización automática de fondo permanente es excelente, por ejemplo, le da un comando anterior cuando ni siquiera recordaba haberlos tipeado una vez. – Florent
Probablemente sea mejor seguir con bash simplemente porque es el más utilizado como caparazón y cualquier tutorial o ayuda que pueda recibir de alguien probablemente usará bash. Sin embargo, he comenzado a usar zsh para todos mis scripts y he encontrado que es muy superior a bash en términos de scripting.
Para escribir guiones reales, prefiero ksh, que tiene varias extensiones útiles para la programación y corrige one of my pet annoyances.
bash es mi preferencia para las sesiones interactivas, pero eso es más una cuestión de preferencia personal que otra cosa. Solo asegúrate de que sea un shell tipo Bourne.
Vine también de csh, tcsh a bash. Es diferente, pero después de un tiempo, al menos tan agradable como las c-shells.
Para secuencias de comandos Recomendaría ksh, porque está disponible en la mayoría de Unixes (Solaris, HP-UX, OSF/1 (el mejor UNIX de la historia;) - para el momento) y tiene buenas características. Con Korn puedes programar la mayoría de los scripts. Esporádicamente, le gustaría obtener más de un número, como valor de retorno de una función, o tiene algunos datos que no puede poner en una matriz simple, o necesita algo que tenga mejores capacidades en caso de regegs, o lo que sea, entonces propondría Perl.
Para las secuencias de comandos, intente utilizar dash por un tiempo para tener una buena idea de lo que es portátil. Si alguna vez usa bash para escribir un script de shell, declare explícitamente bash en los scripts shebang.
Para su uso personal de la consola, experimente con lo que está allí. Encuentre algo con lo que se sienta cómodo. Sea excéntrico y moleste a todos sus amigos de administrador de sistemas al seleccionar un shell que debe compilarse desde el origen para cada máquina que desee utilizar.
LOL. No estoy tratando de hacer enemigos con sysadmin. En la pequeña tienda de desarrollo en la que trabajo, soy mi propio administrador de sistemas. –
Nadie mencionó el estándar basado en Debian para sh, es el shell Debian Almquist dash. Es completamente compatible con POSIX y tiene un arranque muy rápido, por lo que Debian/Ubuntu lo usa para /bin/sh.
Así que uso bash para mi caparazón interactivo, pero solo dash para scripting. De esa forma sé que mis scripts son al menos compatibles con POSIX y se ejecutarán en cualquier otro shell POSIX. ... Sé que la portabilidad es más que el caparazón, pero es donde trazo la línea.
Seleccione uno: a. tcsh b. ksh c. zsh d. iniciar sesión e. bash
Utilizaría el nombre de usuario. Sólo digo.
¿Entiende lo que es un shell de inicio de sesión? No es comparable a tcsh, ksh, zsh, bash, etc. porque es simplemente un shell que se ejecuta cuando su ID de usuario inicia sesión para una sesión interactiva. – nixpower
Creo que FISH es el mejor, tiene resaltado de sintaxis (para comandos que no existen) y puede rellenarse automáticamente. Y es muy fácil de aprender.
OK - su llamada. Pero ... ¿qué caparazón decidiste usar? Creo que eso debería indicar la respuesta que aceptas; Todos entenderán que hay un elemento de subjetividad en esa decisión, ya que los proyectiles son como editores, diferentes personas como diferentes. –
Si alguien se pregunta qué caparazón elegí después de hacer esta pregunta, cambié a bash, pero principalmente porque cambié de compañía. Ocasionalmente, trabajo en el programa en el que estaba en mi antigua empresa, y tengo que volver a csh o tcsh porque eso es lo que están configurados para usar y no vale la pena el costo de reescribir el entorno. –