J'ai utilisé bash, csh et tcsh. Mais j'ai posé cette question et Jonathan m'a informé qu'il ne fallait pas faire confiance à csh. Alors quel shell Linux est bon pour le développement. et pourquoi?
Réponses
Trop de publicités?
Kyle Burton
Points
10471
La plus commune de la coquille, de loin, sur Linux est bash. Sauf si vous avez une bonne raison d'utiliser un autre, je proposerais que de coller avec bash, ou le plus souvent shell utilisé par votre équipe de projet (ou que la majeure partie des scripts shell, vous avez à travailler avec) utilise.
La seule autre très commune candidat est dash, qui est de plus en plus largement utilisés par le projet Ubuntu.
C'est vraiment une préférence personnelle, bien, sauf pour les csh.
SomeDork
Points
321
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 les options de complétion sous la ligne sur laquelle vous travaillez, ce qui est très pratique.
Kirk Strauser
Points
12087
Pour l'interactivité, utiliser Zsh. Pendant un moment j'ai été le responsable de l'entretien des ports de FreeBSD de la fête de l'onglet de l'achèvement de scripts, mais il abandonne dès que j'ai essayé Zsh pour la première fois. Il peut faire tout ce Bash peut faire, mais de plus en plus facilement et de manière plus élégante. Il a également la propriété d'avoir extrêmement Bash-comme les frappes de touches, donc si vous êtes sur un système sans Zsh, vous serez en mesure de le faire (même si elle n'était pas "sentir" comme à nice).
Pour le script, l'utilisation du Bourne Shell (sh). C'est la norme POSIX langage de script et votre scripts sont à peu près garanti pour fonctionner partout. Bash et Zsh et autres coquillages ont de belles extensions que vous allez manquer mais ceux qui vous lient à une installation spécifique. Ignorer que des conseils pour l'utilisation personnelle uniquement les scripts que vous êtes certain que vous ne serez jamais à court d'ailleurs, mais n'oubliez pas que c'est un vrai compromis que vous devez considérer.
Mais en résumé, Zsh. Je ne sais pas de tous ceux qui l'ont essayé qui n'a pas immédiatement et définitivement basculer. Il est vraiment bon.
Myrddin Emrys
Points
7261
Poissons (Amical Shell Interactif) est une bonne alternative à la plupart des autres coquilles. Il a toujours la même syntaxe, nice onglet achèvement et de la syntaxe, il est facile de collecte et d'utilisation (surtout si vous n'avez pas les habitudes des autres shells), et a une excellente exécution de l'aide.
Inconvénient est qu'il est développé de façon erratique, a un petit (mais utile) de l'utilisateur de base, et est très différente de celle d'autres coquilles. Rétro-compatibilité avec shell idiomes n'était pas une priorité.
Dans de nombreux cas, c'est bon... beaucoup de la norme de coquillages ont vraiment stupide façons de faire les choses juste parce que ça a toujours été fait de cette manière. "do/done", "cas/esac", "si/fi"? C'est la folie de ce poisson fait disparaître.
Il vaut la peine de regarder.
Jonathan Leffler
Points
299946
Depuis je crois que je suis la personne qui a suggéré que vous devriez utiliser autre chose que le C Shell, peut-être que je devrait qui devrait se qualifier mes propos légèrement, puis de prendre en charge ceux qui ont dit 'bash sous Linux, shell Korn sur d'autres plates-formes (sauf si bash est installé il y a trop)'.
Un peu comme les éditeurs (vous préférez vim ou emacs), le choix de la coquille est en partie une question de familiarité et en partie une question de préférence. Nombreux sont ceux qui, comme le C shell, mais je crois qu'il est de moins en moins facilement programmable de Bourne shell et les produits dérivés. Ce que j'ai dans mon .cshrc est, en effet, équivalent à exec /bin/ksh (il n'est pas à l'identique, parce que je veux exécuter un shell de connexion - un qui lit le profil et ainsi de suite), mais je ne condamne pas la personne pour l'utilisation de C shell ou un dérivé si c'est une décision éclairée.
Si vous décidez que vous voulez utiliser autre chose que le C shell, puis, vous êtes essentiellement dans le Bourne shell camp, pour qui la norme POSIX plus ou moins spécifie le comportement attendu et puis les différents shells, -- c'est la Bourne, Korn ou Né de Nouveau coques -- ajouter (ou, dans le cas de la classique de la Bourne shell, soustraire) un peu de fonctionnalités. Si votre code pourriez jamais avoir besoin de se déplacer hors de Linux, HP-UX, Solaris, AIX (le survivant du trio de la classique, AT&T dérivé de variantes d'Unix), alors vous devriez envisager de veiller à ce que vous écrivez vos scripts shell classique Bourne shell, bien que Korn shell est aussi assez sûr. Notez, cependant, que sur Linux, vous pouvez écrire #!/bin/sh et obtenir Bash, sur les autres plates-formes, vous obtiendrez Bourne shell.
Je switch entre Korn shell et Bash sans problèmes majeurs - et rarement avec des problèmes mineurs. J'ai tendance à rester à l'écart de ces coins de la langue qui ne sont pas bien définis, ce qui tend à signifier "est définie dans les deux'. Un autre problème pour ceux qui utilisent Linux, c'est que les outils GNU ont plus d'options que les classiques versions d'Unix, et vous pouvez perdre la portabilité non pas à cause de la coquille constructions de programmation que vous utilisez, mais en raison des options de la commande que vous utilisez. L'expérience et l'accès aux pages de manuel de d'autres systèmes d'aide énormément.
