bash vs csh vs others - quel est le meilleur pour la maintenance des applications?
Duplicata possible:
Quel shell Linux dois-je utiliser?
Je commence à maîtriser un environnement Linux et j'essaie de choisir une arme de choix en termes de script de commande Shell (car je suis toujours un gros n00b à ce sujet) qui m'aidera (et d'autres) à gérer, tester et administrer un ensemble d'applications côté serveur s'exécutant sur un environnement * NIX.
Ma question est la suivante: quel (s) est (sont) le (s) shell (s) de commande préféré (s) lorsque les critères suivants sont pris en compte:
Est-il facile d'apprendre/comprendre pour un développeur junior qui n'a jamais été exposé aux scripts Shell?
Existe-t-il un grand bassin de développeurs qui connaissent ce script Shell?
Est-il sûr et facile à utiliser - les erreurs de script seront-elles silencieuses ou donneront-elles une sortie d'erreur intelligente, cela permettra-t-il aux non-initiés de se tirer une balle dans le pied?
Est-il portable? - Puis-je m'attendre à ce que le même script s'exécute dans OpenSolaris ainsi que Redhat, FreeBSD? (la syntaxe de commande et les options accordées pour un système d'exploitation spécifique changeront en conséquence)
Quelle est sa norme? Est-il censé être inclus sur la plupart des distributions de * NIX ou doit-il être installé en plus?
Je comprends qu'il y a des camps qui ont de forts sentiments pour/contre des obus de commandement spécifiques, je cherche juste une opinion éclairée.
De nos jours, à peu près n'importe quel système d'exploitation non intégré (ou grand intégré) possède une couche de compatibilité POSIX: 2001 a.k.a. Single Unix v . Il est natif sur les plates-formes Unix (Linux, Mac OS X, Solaris, * BSD, etc.) et installable sur d'autres plates-formes telles que Windows et Android. POSIX spécifie une langue Shell , généralement connue sous le nom de POSIX sh. Ce langage est dérivé du Bourne Shell.
La plupart des systèmes Unix ont l'une des deux implémentations de POSIX sh: ksh ou bash, qui ont des fonctionnalités utiles supplémentaires par rapport à POSIX. Cependant, certains systèmes moins courants (en particulier ceux intégrés) peuvent ne comporter que des fonctionnalités mandatées par POSIX.
Compte tenu de vos objectifs, je vois trois choix:
- Limitez-vous à POSIX sh. Pro: vous n'avez pas à vous soucier des différentes variantes, car il existe un standard et des implémentations conformes sont facilement disponibles. Inconvénient: vous ne bénéficiez pas des extensions bash et ksh.
- Utilisez l'intersection de ksh et bash. Ceci est attrayant en apparence, mais cela signifie que vous devez utiliser deux documents de référence au lieu d'un seul - et même les fonctionnalités que bash et ksh ont en commun n'utilisent pas toujours la même syntaxe. Déterminer lequel vous souhaitez utiliser sur un système donné est également pénible.
- Choisissez l'un des ksh ou bash. Bash et ksh sont disponibles sur toutes les plateformes de type unix et sur Windows. Les deux ont une implémentation open source (la seule pour bash, ATT ksh93 pour ksh) qui peut être installée sur la plupart des plateformes. J'irais pour bash sur ksh pour deux raisons. Tout d'abord, c'est la valeur par défaut sous Linux, vous trouverez donc plus de gens qui y sont habitués. Deuxièmement, il existe des systèmes livrés avec une implémentation plus ancienne et moins fonctionnelle de ksh; même si vous pouvez installer ksh93, c'est une autre chose à laquelle vous devez penser lors du déploiement.
Oubliez csh pour les scripts et oubliez zsh si vous voulez une disponibilité par défaut commune.
Voir aussi Quelles sont les différences fondamentales entre les shells NIX traditionnels? , en particulier la partie "pour l'écriture de scripts" de ma réponse .
Notez que la programmation Shell implique d'autres utilitaires au-delà du Shell. POSIX spécifie ces autres utilitaires. "Bash plus autres utilitaires POSIX" est un choix raisonnable, distinct de "Utilitaires POSIX (y compris sh)".
csh est presque toujours faux .
Coque Z (zsh)
Il est dit que zsh est le plus puissant pour l'instant, donc je recommanderais de l'essayer.
- Peu importe le Shell que vous apprenez, leur syntaxe est très similaire. Seules les commandes intégrées peuvent légèrement différer. Mais ne choisissez pas ceux anciens et non entretenus.
- Bash est le plus populaire. Mais presque toutes les commandes de bash fonctionnent de la même manière dans zsh. Il y a bien sûr quelques exceptions.
- AFAIK, chaque Shell le gère de la même manière. Mais attention, les shells sont stupides, ils ne sont pas aussi intelligents que les langages de programmation.
- J'ai vu zsh travailler sur tous les Linux, FreeBSD et OpenSolaris.
- Voir 4. Les distros ont zsh dans leurs dépôts.
Pourquoi je préfère zsh (Z Shell) à bash :
- fichiers correspondant à ceci:
for file in ./**/*.Java; do ...(Je veux dire./**/*.ext) - veut que je confirme quand je fais
rm *:) - tab-autocompletion est beaucoup mieux, je peux écrire
dmdomi[tab]et il suggèrednddomainname.Javaveut le nom de classe comme premier paramètre, zsh proposera toutes les classes disponibles dans le paquet et tous les sous-paquets.
Mais vous n'êtes pas limité à zsh uniquement. Si quelque chose ne fonctionne pas pour vous, écrivez-le simplement en bash ou sh. C'est ce qui est "#!/bin/bash" en haut du script pour. :-)
Pour démarrer rapidement, utilisez ma configuration .zshrc: http://www.rozne.geozone.pl/.zshrc La seule chose que vous devez changer est export LANG="pl_PL.UTF-8". Vous ne voulez probablement pas de paramètres régionaux polonais.
Les scripts shell pour tout shell * nix sont généralement d'une simplicité trompeuse. Les choses faciles sont généralement faciles, parfois les choses difficiles sont faciles, parfois les choses qui semblent faciles sont difficiles. Aucun Shell n'est particulièrement meilleur que les autres dans ce domaine mais certains sont pires (je ne peux pas recommander sérieusement csh). Certains diront que bash est le pire Shell "moderne", ce qui peut être vrai, mais vous ne pouvez pas y échapper complètement de toute façon.
Il y a un argument à faire valoir que l'utilisation du Shell le plus `` populaire '' est préférable pour la maintenabilité pour la même raison que Windows est le meilleur (et je ne dis pas que c'est le cas): il est facile de trouver des personnes que vous pouvez embaucher qui savent comment utiliser il. Il y a simplement plus de gens qui ont au moins une familiarité passagère avec les fonctionnalités spécifiques à bash, disons, que ksh ou zsh. Trouver des gens qui comprennent réellement ce qu'ils font est une autre affaire.
Tous les obus ont des accrochages, des cas d'angle et des comportements étranges. Cela se résume principalement à ce à quoi vous êtes habitué. Se tirer dans le pied est ce que j'appellerais une grande tradition Unix et aucun * nix Shell ne peut vraiment vous garder en sécurité.
Presque tous les Shell que vous verrez sont hautement portables sur presque toutes les plateformes. Même si cela est vrai, vous ne serez pas nécessairement en mesure d'exécuter le même script bash (disons) sur trois boîtes différentes, sauf si vous avez fait attention aux utilitaires que vous avez utilisés et aux options que vous leur avez transmises. Il est difficile d'écrire des scripts Shell portables pour des raisons qui n'ont rien à voir avec le Shell pour lequel ils sont écrits.
Presque tous les Linux utilisent bash par défaut et ont la plupart des shells disponibles. FreeBSD inclut par défaut sh, csh et tcsh avec bash et autres dans les ports. Il y a longtemps, Mac OS X utilisait tcsh par défaut, mais il utilise maintenant bash par défaut et inclut zsh avec les shells les plus courants. Au-delà, je ne peux rien dire.
Personnellement, j'utilise bash hors (principalement) de l'inertie. Si je ne le connaissais pas déjà, j'utiliserais plutôt zsh.
bash est la norme et est très bon pour une utilisation interactive (bonne exécution prenant en charge de nombreux programmes, historique, prise en charge de la ligne de lecture, nombreux types d'expansion de chaînes). Il est également bon en script, pour un shell (tableaux et hachages, citation, manipulation de chaînes); bien que l'écriture de scripts fiables vous oblige à en apprendre beaucoup plus.
Si vous voulez que vos programmes puissent se développer, travailler avec des structures de données élaborées et utiliser des bibliothèques utiles, vous devriez apprendre un langage comme python, Ruby ou Perl. La plupart d'entre eux ont des interprètes interactifs aussi, pas aussi pratique qu'un Shell mais utile pour des tests rapides. IPython, pour Python, est particulièrement utile; il vous permet d'explorer la documentation très facilement, peut charger et recharger la source, comprend un débogueur. Il comprend également quelques commandes Shell standard et peut passer le reste à un Shell standard en les préfixant avec un !.
- Grâce à leur interactivité, la plupart des shells sont assez faciles à apprendre une fois que vous les utilisez exclusivement
- Je crois que bash, et le sous-ensemble posix, sont mieux connus par une large marge. Mais les langues que j'ai mentionnées sont aussi connues que de nombreux obus.
- Vous pouvez facilement vous tirer une balle dans le pied, la commodité facilite souvent les choses indésirables.
- et 5. La portabilité du shell lui-même ne devrait pas être un problème; vous devrez peut-être recompiler pour obtenir des fonctionnalités plus modernes sur certains des systèmes d'exploitation que vous mentionnez. L'utilisation d'un langage complet avec ses propres bibliothèques aidera à atténuer la variation de votre multiplicité de plates-formes.