Quel shell Linux devrais-je utiliser?
J'ai utilisé bash, csh et tcsh. Mais j'ai demandé cette question , et Jonathan m'a informé que csh n'est pas fiable. Alors, quel shell Linux est bon pour le développement. et pourquoi?
Le shell le plus répandu sous Linux est de loin bash. À moins que vous n’ayez une bonne raison d’utiliser une alternative, je vous conseillerais de vous en tenir à bash, ou au shell le plus couramment utilisé par votre équipe de projet (ou à l’ensemble des scripts Shell à travailler).
Le seul autre concurrent très courant est dash, qui est de plus en plus utilisé par le projet Ubuntu.
C'est vraiment une préférence personnelle, sauf pour csh .
Je préfère zsh.
La complétion par onglet en vaut la peine:
- Il développe les caractères génériques si vous le souhaitez (pratique lorsque vous souhaitez supprimer tous les fichiers sauf un dans un répertoire)
- Vous donnera une liste de commutateurs après avoir spécifié un programme
- Donne des options de complétion sous la ligne sur laquelle vous travaillez, ce qui est très pratique.
Pour l'interactivité, utilisez Zsh. Pendant un certain temps, j'étais responsable du portage des scripts de complétion de tabulation Bash sous FreeBSD, mais je l'ai abandonné dès que j'ai essayé Zsh pour la première fois. Il peut faire tout ce que Bash peut faire mais plus facilement et plus élégamment. Il possède également la propriété Nice d'avoir des frappes extrêmement Bash-like, donc si vous êtes sur un système sans Zsh, vous pourrez vous débrouiller (même si cela ne vous "sentait pas" comme Nice).
Pour les scripts, utilisez Bourne Shell (sh). C'est le langage de script standard POSIX et vos scripts sont pratiquement garantis pour fonctionner partout. Bash, Zsh et d’autres coques ont de jolies extensions qui vous manqueront, mais celles-ci vous lient à une configuration spécifique. Ignorez ce conseil pour les scripts à usage personnel uniquement que vous êtes certain de ne jamais exécuter ailleurs, mais souvenez-vous que c'est un véritable compromis que vous devez prendre en compte.
Mais en résumé, Zsh. Je ne connais personne qui l'ait essayé qui ne l'ait pas immédiatement et définitivement changé. C'est vraiment bon.
Poisson (Friendly Interactive Shell) est une alternative intéressante à la plupart des autres coquillages. Il a une syntaxe cohérente, la complétion des onglets Nice et la coloration syntaxique, est facile à extraire et à utiliser (surtout si vous n’avez pas d’habitude d’autres shell), et dispose d’une excellente aide à l’exécution.
L'inconvénient est qu'il est développé de manière erratique, qu'il a une base d'utilisateurs réduite (mais utile) et qu'il est très différent des autres shells. La compatibilité avec les idiomes de Shell n’était pas une priorité.
Dans de nombreux cas, c’est une bonne chose… beaucoup de coquilles standard ont des façons vraiment stupides de faire les choses, simplement parce que cela a toujours été fait de cette façon. "do/done", "case/esac", "if/fi"? C'est la folie que le poisson supprime.
Ça vaut le coup d'oeil.
Puisque je crois que je suis la personne qui a suggéré que vous utilisiez autre chose que C Shell, je devrais peut-être nuancer mes remarques, puis soutenir ceux qui ont déclaré «bash sur Linux, Korn Shell sur d’autres plateformes (sauf si bash est installé ici aussi)'.
Un peu comme les éditeurs (préférez-vous vim ou emacs), le choix de Shell est en partie une question de familiarité et en partie une question de préférence. Nombreux sont ceux qui aiment C Shell, bien que je pense qu'il est moins facilement programmable que Bourne Shell et ses dérivés. Ce que j'ai dans mon .cshrc est en effet équivalent à exec /bin/ksh (ce n'est pas identique parce que je veux exécuter un shell de connexion - un qui lit le profil, etc.), mais je ne condamnerais personne pour avoir utilisé C Shell ou un dérivé s’il s’agit d’une décision éclairée.
Si vous décidez d’utiliser quelque chose d’autre que C Shell, alors vous êtes essentiellement dans le camp Bourne Shell, pour lequel le standard POSIX spécifie plus ou moins le comportement attendu, puis les différents shells - c’est-à-dire Bourne, Korn. Coques Born Again - ajoutez (ou, dans le cas du classique Bourne Shell, soustrayez) quelques caractéristiques. Si votre code doit éventuellement être déplacé de Linux vers HP-UX, Solaris ou AIX (le trio restant des variantes Unix classiques dérivées d'AT & T), vous devez envisager de vous assurer d'écrire vos scripts Shell dans Bourne Shell classique, bien que Korn Shell est également très en sécurité. Notez cependant que sous Linux, vous pouvez écrire #!/bin/sh et obtenir Bash, sur les autres plates-formes, vous obtiendrez Bourne Shell.
Je bascule entre Korn Shell et Bash sans problèmes majeurs - et rarement avec des problèmes mineurs. J'ai tendance à rester à l'écart des coins de l'une ou l'autre langue qui ne sont pas bien définis - ce qui signifie généralement «définis dans les deux». Un autre problème pour ceux qui utilisent Linux est que les outils GNU ont plus d'options que les versions Unix classiques et que vous pouvez perdre la portabilité non pas à cause des constructions de programmation Shell que vous utilisez, mais à cause des options de commande que vous utilisez. Une expérience et un accès rapide aux pages de manuel d'autres systèmes sont d'une aide précieuse.
Je m'en tiens généralement à bash, car il est plus convivial que shigh-up, et c'est le comportement par défaut de toutes les distro que j'ai utilisées de manière semi-régulière (SuSE, RHEL, Ubuntu, Slackware).
Si vous envisagez d'écrire des scripts Shell portables, assurez-vous qu'ils s'exécutent tous dansrealsh.
Frapper. C'est standard.
Le problème avec csh est que c'est la merde pour les scripts, comme expliqué ici . Il n'y a pas de vraie raison pour que vous ne l'utilisiez pas comme un shell interactif, mais la plupart des gens trouvent déroutant d'apprendre deux shells différents et de ne pas pouvoir essayer des fragments de leurs scripts sur la ligne de commande. pareil pour tout.
Les candidats évidents pour un shell interactif sont bash, dash, zsh et {pd,} ksh. Tous implémentent le standard posix Shell, avec quelques extensions mineures. Choisissez celui que vous préférez pour une utilisation interactive, j'aurais tendance à utiliser bash simplement parce que c'est la norme sur linux mais ils ont tous leurs mérites et zsh en particulier semble populaire.
Si vous écrivez un script que vous avez l'intention de transférer, utilisez #!/Bin/sh et assurez-vous d'utiliser la syntaxe standard posix Shell. Si cela fonctionne sur bash et ksh, c'est probablement la norme. Il y a de vieilles versions d'Unix qui ont un/bin/sh non standard, mais je ne m'en soucierais pas si vous ne le savez pas. Les problèmes de portabilité sont tous les outils de ligne de commande que vous appelez à partir de votre script.
Personne n'a mentionné la norme basée sur Debian pour sh, c'est le shell Debian Almquist dash. Il est entièrement conforme à POSIX et a un démarrage très rapide, raison pour laquelle Debian/Ubuntu l’utilise pour /bin/sh.
J'utilise donc bash pour mon shell interactif, mais seulement dash pour les scripts. De cette façon, je sais que mes scripts sont au moins compatibles POSIX et s’exécutent sur n’importe quel autre shell POSIX. ... Je sais que la portabilité est plus que le Shell, mais c'est là que je trace la ligne.
Je ne suis pas un grand utilisateur de Ruby mais http://Rush.heroku.com/ a l'air intéressant
Il est probablement préférable de s'en tenir à bash simplement parce que c'est le shell le plus utilisé et que tous les tutoriels ou l'aide que vous pourriez recevoir de quelqu'un utiliseront probablement bash. Cependant, j'ai commencé à utiliser zsh pour tous mes scripts et je l'ai trouvé bien supérieur à bash en termes de script.
Mais n'utilisez pas Korn Shell (ksh).
Sauf si vous avez saisi parfaitement et n'avez jamais besoin d'utiliser la touche de retour arrière.
J'aime ksh en fait. C'est un peu plus cohérent que bash car il n'essaye pas de supporter les constructions csh. tcsh, selon mon expérience, est le moins compatible avec les autres coques et je l’évite. J'essaie d'écrire des scripts pour sh, mais ksh a quelques fonctionnalités intéressantes comme l'exportation et la définition d'une variable sur une ligne. J'essaie également de préserver la compatibilité avec bash, car elle est complète et commune. Pour écrire des scripts de shell portables, ce qui est plus important que de choisir le "meilleur" shell, vous pouvez consulter ce livre.
Programmation de shell portable: Une vaste collection d’exemples de Bourne Shell (série professionnelle HP) par Bruce Blinn (Paperback - 29 oct. 1995) Amazon.com
Pour l'écriture de scripts, essayez pendant un moment d'utiliser dash pour avoir une idée précise de ce qui est portable. Si vous utilisez jamais bash pour écrire un script shell, veuillez déclarer explicitement bash dans les scripts Shebang.
Pour votre utilisation de la console personnelle, testez ce qui existe. Trouvez quelque chose avec lequel vous êtes à l'aise. Soyez excentrique et agacez tous vos amis administrateurs système en choisissant un shell qui doit être compilé à partir des sources pour chaque machine sur laquelle vous souhaitez les utiliser.
J'utilise pdksh tout le temps sans avoir rien à faire pour taper parfaitement (vous avez peut-être besoin de réparer votre termcap?)
ksh est le standard, csh est un standard et bash est 'standard', mais sous linux uniquement. Mieux vaut cibler ksh.
Pour écrire des scripts réels, je préfère ksh, qui possède plusieurs extensions utiles pour la programmation et corrige un de mes ennuis de compagnie .
bash est ma préférence pour les sessions interactives, mais il s’agit plus d’une question de préférence personnelle que d’autre chose. Assurez-vous simplement qu'il s'agit d'un shell de type Bourne.
Je viens aussi de csh, tcsh à bash. C'est différent mais après un certain temps, au moins aussi gentil que les coquillages.
Pour les scripts, je recommanderais ksh, car il est disponible sur la plupart des systèmes Unix (Solaris, HP-UX, OSF/1 (le meilleur système UNIX de tous les temps;) - pour son temps)) et qu'il possède de bonnes fonctionnalités. Avec Korn, vous pouvez programmer la plupart des scripts. Sporadicalement, vous voudriez obtenir plus qu’un nombre, comme valeur de retour d’une fonction, ou vous avez certaines données que vous ne pouvez pas mettre dans un tableau simple, ou vous avez besoin de quelque chose qui a de meilleures capacités en cas de regegs, ou quoi que ce soit, alors je proposerais Perl.
Je pense que FISH est le meilleur, il a la coloration syntaxique (pour les commandes qui n'existent pas) et il peut se remplir automatiquement. Et c'est très facile à apprendre.