Est-il recommandé d'utiliser zsh au lieu des scripts bash? [fermé]

Puis-je supposer que suffisamment de personnes ont zshinstallé pour exécuter des scripts avec un

#!/usr/bin/env zsh

comme shebang?

Ou est-ce que cela rendra mes scripts non exécutables sur trop de systèmes?

Clarification: je suis intéressé par les programmes / scripts qu'un utilisateur final pourrait vouloir exécuter (comme sur Ubuntu, Debian, SUSE, Arch & c.)

Pour la portabilité, non. Bien qu'il zshpuisse être compilé sur n'importe quel Unix ou Unix-like et même Windows au moins via Cygwin, et qu'il soit conditionné pour la plupart des likes Unix Open Source et plusieurs commerciaux, il n'est généralement pas inclus dans l'installation par défaut.

bashà l'autre bout est installé sur les systèmes GNU (tout comme bashle shell du projet GNU) comme la grande majorité des systèmes basés sur Linux non embarqués et parfois sur des systèmes non GNU comme Apple OS / X. Dans le côté Unix commercial, le shell Korn (la variante AT&T, bien que plus ksh88celle) est la norme et les deux bashet zshest dans des packages optionnels. Sur les BSD, le shell interactif préféré est souvent tcshalors qu'il shest basé sur le shell Almquist ou pdkshet bashou zshdoit également être installé en tant que packages optionnels.

zshest installé par défaut sur Apple OS / X. C'était même /bin/shlà. Il peut être trouvé par défaut dans quelques distributions Linux comme SysRescCD, Grml, Gobolinux et probablement d'autres, mais je ne pense pas que les principales.

Comme pour bash, il y a la question de la version installée et par conséquent des fonctionnalités disponibles. Par exemple, il n'est pas rare de trouver des systèmes avec bash3ou zsh3. De plus, il n'y a aucune garantie que le script pour lequel vous écrivez maintenant zsh5fonctionnera zsh6bien que, comme bashils essaient de maintenir la compatibilité descendante.

Pour les scripts, ma vision est la suivante: utilisez la syntaxe du shell POSIX car tous les Unices ont au moins un shell appelé sh(pas nécessairement dedans /bin) capable d'interpréter cette syntaxe. Ensuite, vous n'avez pas à vous soucier autant de la portabilité. Et si cette syntaxe ne suffit pas à vos besoins, vous avez probablement besoin de plus qu'un shell.

Ensuite, vos options sont les suivantes:

• Perl qui est omniprésent (mais encore une fois, vous devrez peut-être vous limiter à l'ensemble des fonctionnalités des anciennes versions et ne pouvez pas faire d'hypothèses sur les modules Perl installés par défaut)
• Spécifiez l'interpréteur et sa version (python 2.6 ou supérieur, zsh 4 ou supérieur, bash 4.2 ou supérieur ...), comme dépendance pour votre script, soit en construisant un package pour chaque système ciblé qui spécifie la dépendance, soit en le stipulant dans un fichier README livré avec votre script ou incorporé sous forme de commentaires en haut de votre script, ou en ajoutant quelques lignes dans la syntaxe Bourne au début de votre script qui vérifie la disponibilité de l'interpréteur demandé et sort avec une erreur explicite quand ce n'est pas le cas, comme ce script a besoin de zsh 4.0 ou supérieur .
• Expédiez l'interpréteur à côté de votre script (méfiez-vous des implications de licence), ce qui signifie que vous avez également besoin d'un package pour chaque système d'exploitation ciblé. Certains interprètes facilitent la tâche en fournissant un moyen de regrouper le script et son interpréteur dans un seul exécutable.
• Écrivez-le dans une langue compilée. Encore une fois, un package par système ciblé.

Non tu ne peux pas. Ce qui est garanti disponible /bin/sh, c'est essentiellement la coque Bourne d'origine. Presque toutes (notez le "presque"!) Les installations Linux auront bash, mais sur les systèmes * BSD c'est rare (la persécution BSD a de sérieuses réserves sur le code GPL, comme bash). Je ne sais pas quel est le shell standard sur Mac, mais encore une fois, il y a des doutes sur GPL. Idem pour Solaris.

zsh est un shell de niche, il n'est pas dans l'installation par défaut de Fedora (et je ne pense pas qu'il soit par défaut pour une distribution majeure).

Je pense que cela dépend vraiment des fonctionnalités supplémentaires de zsh que vous utilisez et où. Si vous prévoyez de distribuer votre script entre les différents utilisateurs et systèmes, je vous suggère d'utiliser bash ou même sh .

En même temps, si votre script est conçu pour être exécuté dans toute votre organisation et que vous avez la convention d'avoir zsh sur vos machines (par exemple la même AMI de base) et que votre tâche a des avantages évidents avec des extensions telles que des sélecteurs de fichiers avancés ou d'autres éléments de http: / /www.rayninfo.co.uk/tips/zshtips.html Je dirais, allez-y!

Comme indiqué, bashest généralement disponible dans l'installation par défaut pour de nombreuses distributions. Votre script n'atteindra pas la plus grande base d'utilisateurs en s'appuyant sur zsh.

Une question importante à laquelle répondre avant de concevoir votre script est " Pourquoi est-il important dans quel shell un script est exécuté? "

Différents shells utilisent une syntaxe différente ou offrent des fonctions de shell supplémentaires qui peuvent ne pas être prises en charge par d'autres shells. Pour écrire un script pour le «monde général des utilisateurs finaux de linux», déterminez si votre script utilise une syntaxe ou des fonctions shell qui reposent sur un environnement shell particulier.

Par exemple, bashshell prend en charge certaines extensions qui ne sont pas prises en charge par dash, Bourne shell, ou tout ce qui /bin/shpointe sur le système de l'utilisateur.

$ ls -l /bin/sh 
lrwxrwxrwx 1 root root 4 Feb 19  2014 /bin/sh -> dash

Essayez d'exécuter echo {1..10}avec /bin/shpar rapport à /bin/bashet vous obtiendrez une sortie très différente.

Il en va de même pour zshqui, tout en prenant en charge la plupart des bashsyntaxes, offre une extension et une syntaxe supplémentaires qui ne sont pas prises en charge par le bashshell. Voir ces tableaux comparant des shells pour des exemples spécifiques.

Vous pouvez élargir votre base d'utilisateurs potentiels au-delà bashen adhérant à des scripts qui fonctionnent lorsqu'ils sont appelés #!/bin/sh -u. Cependant, cela soulève une autre question importante à se poser: " Qu'est-ce qui est sacrifié en échange d'une plus grande portabilité? "

Déterminez si les différences relatives aux problèmes de sécurité, aux fonctionnalités, à l'efficacité ou à tout autre élément que vous jugez prioritaire pour votre script valent le sacrifice. Il se peut que vous ne souhaitiez pas une large utilisation d'un script avec une vulnérabilité de sécurité connue simplement parce qu'il fonctionne dans plus d'environnements.

De nombreux scripts sont écrits pour bashque la prise en charge de ces scripts soit utilisée comme critère lors de la comparaison des shells de commande . Beaucoup plus de personnes pourront exécuter votre script que s'il s'appuie sur zshou sur toute autre syntaxe exclusive à un environnement shell.

Gardez également à l'esprit que vous n'avez finalement pas le contrôle sur la façon dont l'utilisateur exécute le script (également utile pour déboguer des scripts dans différents shells ):

N'oubliez pas que si vous utilisez un shell pour lire un script shell («sh scriptname»), au lieu de l'exécuter directement («./scriptname»), le shell traitera tous les commentaires au début du script shell comme des commentaires. En particulier, le commentaire qui spécifie l'interpréteur à utiliser lors de l'exécution du script («#! / Bin / sh -u») sera ignoré, de même que toutes les options répertoriées à côté de cet interpréteur.

Donc, le mieux que vous puissiez faire à ce sujet est de rendre vos scripts portables, tant qu'il n'y a pas de gros sacrifices à la façon dont il fonctionne.

Vous pouvez également voir les conventions de codage Bash - Débordement de pile .

La seule chose que vous pouvez presque garantir, c'est /bin/sh . Il peut s'agir d'un shell lié statique ou d'un lien vers un autre shell. Cet autre shell détecte généralement qu'il est appelé sh et s'exécutera en mode de compatibilité.

Remarquez le presque dans la première phrase.

Chaque système de type Unix sur lequel j'ai jamais travaillé l'avait. Beaucoup d'entre eux avaient également installé bash (mais pas tous . Par exemple, bash n'est pas installé par défaut sur certains BSD. livrées DASH , le shell Debian Almquist à la place.

Ce que vous pouvez garantir, ce sont vos instructions d'installation. Vous pouvez ajouter une ligne au fichier README indiquant que c'est zsh nécessaire. Si vous créez un package, vous pouvez marquer zsh comme une dépendance. Vous pouvez le vérifier avec les outils autoconf / automake. Vous pouvez vérifier si zsh est trouvé avec dans le script d'installation (commencez par / bin / sh et essayez de localiser zsh, s'il est trouvé, continuez. Sinon, affichez une erreur. Par exemple "Avertissement: ZSH n'est pas installé. Veuillez lire le fichier d'instructions d'installation! ".)

Je suis sûr d'avoir oublié quelques options supplémentaires. Mais les points clés sont:

• Vous ne pouvez rien garantir tant que vous ne l'avez pas vérifié.
• Vous êtes presque assuré que / bin / sh est présent, et que vous pouvez vérifier cela.