Meilleure réponse
Ce sont tous des shells, et il y en a beaucoup dautres que vous navez pas mentionnés. Celui que vous choisissez dutiliser est une question de préférence personnelle.
Le premier shell était le Bourne Shell (ou sh) et cétait la valeur par défaut sous Unix pendant longtemps. Puis une dérivation majeure dans Unix est arrivée, et un nouveau shell a été créé à partir de zéro appelé le Shell C (ou csh). Le Bourne Shell vieillissant a ensuite été suivi par le compatible mais beaucoup plus puissant Korn Shell (ou ksh). Les shells disponibles appartiennent généralement à lune de ces catégories: dérivé Bourne / Korn Shell (bash), dérivé ou clone C Shell (tcsh) ou « autre » (comme zsh).
Il existe de nombreux shells pour choisissez parmi, et pas seulement ceux que vous avez mentionnés. GNU bash fait partie du camp Bourne / Korn Shell et est aujourdhui le shell par défaut sur une grande variété de variantes Unix et Linux. Si vous avez utilisé un terminal shell sous Unix ou Linux, il y a de fortes chances que ce soit celui-ci. Si vous voulez vraiment et vraiment Bourne Shell (sh), je crois quil est maintenant disponible gratuitement – mais il est généralement évité comme nayant pas assez de fonctionnalités. Le Korn Shell est rétrocompatible, et est également gratuit sous la forme de clones (mksh) et de loriginal récemment publié (ksh).
Pour C Shell, il existe tcsh, un clone étendu du csh original Il y a moins de clones csh parce que csh na pas été vu comme une voie à suivre et na pas autant dutilisateurs – cependant, de nombreuses versions BSD dUnix (comme FreeBSD et dautres) utiliseront csh comme shell par défaut.
Il existe des variantes qui ne sont ni compatibles avec sh / ksh ni csh – mais elles ont tendance à être des shells de niche. Mes favoris dans cet espace seraient le Scheme Shell (scsh) et le shell Plan 9 rc – mais ceux-ci ne sont jamais installés par défaut sur Unix ou Linux et le premier est plutôt gros. zsh fait également partie de cette catégorie « autre ».
Ma recommandation est triple: dabord, essayez le shell par défaut sur votre système – presque certainement GNU bash. Bash est partout, et lira et exécutera les programmes Bourne Shell et Korn Shell sans incompatibilités. Deuxièmement, essayez chacun des shells que vous voulez vraiment essayer (tels que zsh ou tcsh), travaillez avec lui pendant un moment et voyez sil répond à vos besoins. Enfin, utilisez simplement celui qui vous convient.
Notez que vous ne « t devez écrire des scripts dans le shell que vous utilisez: Jai utilisé le C Shell de manière interactive, mais jai refusé de le programmer (tous mes scripts utilisaient le Korn Shell). Enfin, un jour, jai plongé dans ksh et je nai jamais regardé en arrière.
Mes favoris personnels à ce sujet point sont mksh (un clone de Korn Shell sans extensions) – ou GNU bash avec une compatibilité totale avec Korn Shell – ou rc , le shell du nouveau système dexploitation Plan 9 qui était censé être un successeur dUnix (bien que cela ne se soit pas matérialisé).
Réponse
Mieux pour quoi?
Quels sont vos critères?
Personnellement, je suggère bash car cest la valeur par défaut sur les systèmes Linux et MacOS X et facilement disponible sur toutes les autres formes dUnix et sous MS Windows via Cygwin et est la valeur par défaut pour les Services Microsoft ™ Windows pour Linux « (couche / sous-système de support Ubuntu bash ).
Fondamentalement, cest le chemin de la moindre résistance si vous comptez exploiter de nombreux systèmes différents pendant de nombreuses années … et accéder fréquemment à des systèmes fraîchement réimagés ou à des instances lancées récemment avec des écarts minimes par rapport à la base du système dexploitation (comme est courant pour les batteries de serveurs Web / dapplications mises à léchelle). Il est suffisamment proche du shell Korn que peu de gens trouveront les cas dangle où ils diffèrent dans la sémantique. (La plupart des utilisateurs ne remarqueront pas la différence entre des clones Bourne Shell plus minimaux tels que ash et dash et les fonctionnalités ajoutées par bash , encore moins être en mesure de faire la distinction entre les différences entre ksh et bash .
zsh est probablement le plus puissant et personnalisable. Il convient mieux à quelquun qui est vraiment passionné par lutilisation et la personnalisation de son shell. Linconvénient de lutiliser… avec toutes ses améliorations et personnalisations… est que lutilisateur est susceptible de trouver frustrant de renoncer à utiliser un autre shell lorsque problèmes de débogage sur les systèmes où zsh na pas (encore) été installé – ce que font assez fréquemment les administrateurs des opérations / sysadmins dans les environnements modernes.Cest également assez peu pratique lorsque vous travaillez avec des collègues ou que vous encadrez des collègues et que vous essayez de leur montrer quelque chose à linvite du shell ou de partager un écran GNU ou tmux session avec eux.
Le shell Korn, ksh , est un meilleur shell pour les scripts que bash en quelques petits détails… mais pas assez pour valoir la peine de le récupérer, linstaller et le configurer partout.
ksh a pris en charge les « tableaux associatifs » (hachage / dictionnaires) pendant de nombreuses années avant que bash ne lajoute. (Il a été ajouté à bash il y a seulement quelques années, nest toujours pas inclus dans les versions livrées avec MacOS X par défaut, par exemple). Il est donc généralement préférable de ne pas utiliser de tableaux associatifs dans vos scripts shell. Si vous pensez que vous voulez ses fonctionnalités, il est généralement préférable de passer à Python, Ruby, Perl, TCL / wish ou lun des nombreux autres langages de script à usage général . Il ny a tout simplement pas grand chose à gagner à passer à un shell différent (en termes de surcharge opérationnelle) uniquement pour cette fonctionnalité.
On peut en dire autant de ksh Coprocessus .
La seule autre différence notable est celle qui doit être expliquée. Considérez la commande shell suivante:
unset foo; echo bar | read foo; echo "$foo"
Ceci est parfaitement valable dans nimporte quel shell compatible Bourne. Mais il se comportera différemment sous différentes coquilles. Il émettra soit la chaîne «bar» (et une nouvelle ligne) soit il émettra juste la ligne vide.
bash fera laffaire ce dernier, tandis que ksh et zsh fonctionneront de la première manière. La variable shell «foo» sera définie dans le shell actuel. À mon avis, c’est la sémantique préférée.
Mais c’est un cas secondaire. Autant que je sache, il n’est pas couvert par les spécifications Posix du shell Unix; donc le fait que le comportement dépende de limplémentation nest pas un bogue. Cest simplement quelque chose dont un expert dans le shell doit être conscient et tester ou contourner.
La raison de ce comportement est que lopérateur «pipe» dans le shell est une communication inter-processus mécanisme. Le shell doit créer un sous-shell, cest-à-dire un sous-processus exécutant sa propre copie de la mémoire du processus parent. Cependant, toute implémentation donnée peut analyser la commande et exécuter soit la partie avant (à gauche de) le symbole de tube dans le sous-shell (comme cela est fait par ksh et zsh ) ou après (à droite de) le tube (comme fait par bash, très anciennes versions de ksh (avant la version 1983?) et lancien Bourne shell et la plupart de ses clones tels que ash et dash .
Une œuvre autour consiste à utiliser le regroupement de commandes pour sassurer que toutes les commandes après le tube sont « dans la portée » avec le read intégré comme ceci:
unset foo; echo bar | { read foo; echo "$foo"; }
(Incidemment, cet exemple expose un bug subtil qui existait dans bash avant la version 1.4 et qui a été corrigée par la suite; lanalyseur utilisé pour traiter {} les caractères et les jetons ve ry un peu comme le () (parenthèses). Donc, il tolérait de laisser de côté ce point-virgule après mon echo « $ foo » – ce qui était, techniquement, un écart par rapport à la spécification. Le problème est que des millions de personnes utilisaient bash et écrivaient des scripts en partant du principe qu’ils n’avaient pas besoin de terminer leur commande avant une accolade fermante – avec un point-virgule ou une nouvelle ligne. Donc, certains de ces anciens scripts shell présentent toujours ce bogue bien plus dune décennie plus tard et il ny a quune poignée de personnes qui connaissent suffisamment bien le shell pour le repérer et le corriger).
Quant à lutilisation interactive, bash est clairement supérieur à ksh mais probablement pas tout à fait à égalité avec zsh pour toute personne qui sengagerait à apprendre et à utiliser des améliorations et des personnalisations extrêmement délicates.
bash prend en charge la complétion [Tab] programmable et les bibliothèques GNU readline pour un contrôle extrêmement flexible sur les raccourcis clavier, lédition de la ligne de commande et laccès à lhistorique des commandes. ksh a la commande fc relativement limitée (qui bash prend également en charge) pour votre «commande de correction», cest-à-dire pour sélectionner des éléments de votre historique, les extraire dans votre éditeur de texte préféré et exécuter automatiquement le contenu de ce fichier temporaire modifié à la sortie.
Mais bash prend en charge cela et ses propres emacs ou vi laccès et lédition de lhistorique, et lancien csh ! (bang) également.
bash prend en charge la modification vi mode ( set -o vi ) qui était, si je me souviens bien, la valeur par défaut dans ksh 93. Mais bash utilise par défaut le mode emacs ( set -o emacs ). De plus, bien sûr, on peut également utiliser la commande bash bind pour relier tout touches à lune des nombreuses fonctions dédition et de manipulation dhistorique, ou dans des macros se développant dans nimporte quel texte que vous voudrez peut-être mettre sur une ligne de commande.
De plus bash a de nombreuses variables denvironnement «magiques» qui peuvent faire des choses qui sont presque inimaginablement subtiles et complexes. Par exemple, vous pouvez définir la variable PROMPT\_COMMAND pour exécuter un hook personnalisé chaque fois que bash est sur le point de présenter son invite. Ainsi, vous pourriez avoir cette vérification pour une certaine magie .dot\_file et re-personnaliser votre shell en cours dexécution en fonction du répertoire dans lequel vous vous trouvez, ou réinitialiser votre chaîne dinvite et les couleurs de lécran du terminal en fonction de lheure de la journée, ou interrogez un site Web et exécutez automatiquement une commande basée sur… à peu près nimporte quoi.
(Jai utilisé ce hook pour activer automatiquement les environnements virtuels Python en passant simplement à leur répertoire de travail par exemple).
Lorsque vous considérez tcsh (ou son ancêtre, csh ) alors vous êtes dans une niche. Il est courant de voir des scripts csh dans le domaine de lEDA (automatisation de la conception électronique). Mais cest un accident de lhistoire et la plupart des personnes travaillant dans ce domaine nutilisent pas tcsh pour leur utilisation interactive.
Le tcsh div id = « 0ec9e18bff »> poisson la coquille est également une niche. Je ne l’ai jamais assez utilisé pour me faire une opinion, et c’est certainement assez coloré. Mais je pense quil va avoir une rangée très difficile à biner avant de cultiver un public vraiment répandu. À moins quApple ™ ne commence à lexpédier comme shell par défaut pour leurs systèmes Mac ™, il est probablement voué à rester dans son créneau dans un avenir prévisible.
Jespère donc avoir fait le point. Il ny a vraiment pas grand intérêt à se demander «quel est le meilleur…» (à peu près nimporte quelle chose où il existe des alternatives raisonnables).
Dans le cas des shells de commande Unix, les différences entre les shells compatibles Bourne sont si minimes que seuls les experts peuvent les distinguer, et ceux-ci ont des compromis et finissent par se résumer à des préférences plutôt subjectives. Jai des collègues qui sont passionnés par leurs paramètres zsh et dautres qui sen soucient. Je me situe quelque part entre mon adaptation au choix le plus facilement disponible.