Le langage de script le plus universel pour Linux est?


24

Nous écrivons des scripts pour les systèmes Linux, il y a eu un débat sur ce qui serait le langage de script actuel le plus universellement Linux à utiliser. Bash, SH, Posix? Quelle?


3
Je suppose sh.
Blender

Avez-vous une liste de distributions cibles? Ou des distributions obligatoires / souhaitables sur lesquelles il doit fonctionner?

4
"sh"? Quel sh"? La coque Thomson? la coquille de Bourne? bash, ksh, pdksh, ash, zsh comme /bin/shsur le système X ou Y ? La spécification sh POSIX, La spécification sh SUSv3, SUSv4, la spécification sh LSB? "sh" en soi ne veut rien dire.
Stéphane Chazelas

1
s'il s'agit de versions de logiciels et de scripts d'installation, vous voudrez peut-être consulter Autotools, qui tente de résoudre les problèmes de compilation inter-systèmes.
Lie Ryan

1
@sch L'intersection commune la plus portable, "évidemment". Au cas où des personnes peu familières avec les coquilles Unix seraient induites en erreur par votre commentaire, la spécification POSIX est implémentée par presque toutes les coquilles contemporaines qui osent porter le nom sh, et les non conformes shqui ne sont pas anciennes et rares de nos jours (par exemple Bourne). On peut créer une liste sans cesse croissante d'extensions et de variations, mais si l'objectif est «universel» ou portabilité, il faut aller dans la direction opposée. La réponse de Gilles couvre les détails plus en profondeur.
jw013

Réponses:


38

Il existe deux environnements de programmation disponibles sur tous les systèmes d'exploitation de type Unix, Turing-complete et capables d'appeler d'autres programmes: awk et sh , la famille de shell Bourne / POSIX. AWK est orienté vers le traitement de texte (il complète des utilitaires plus spécialisés), tandis que sh est orienté vers un langage de collage pour assembler des programmes. Sh est le langage de script universel sur Linux et dans le monde Unix.

La norme POSIX définit les fonctionnalités obligatoires de sh lui-même et des utilitaires associés. La plupart des systèmes de type Unix sont conformes à POSIX 1003.1-2004 (alias Single Unix v3, alias Open Group Base Specification issue 6); la dernière version de cette norme est POSIX 1003.1-2008 (alias Single Unix v4, alias Open Group Base Specification Issue 7).

Chaque système Linux et Unix ou Unix-like a un shell de style Bourne sur le chemin /bin/sh, et tout système non antique a un shell conforme POSIX (sauf le bogue occasionnel). Chaque système moderne de type Unix (y compris Linux) prend en charge les shebangs , il exécute donc automatiquement les scripts /bin/shsi la première ligne l'est #!/bin/sh. Il existe des systèmes POSIX qui shsont situés à un autre endroit (généralement des couches d'émulation sur des systèmes d'exploitation que vous ne penseriez pas vraiment être de type Unix).

Les systèmes Linux embarqués peuvent avoir un système BusyBox allégé qui n'implémente pas toutes les fonctionnalités POSIX. BusyBox dispose d'un grand nombre d'options au moment de la compilation pour s'adapter aux systèmes à faible encombrement, il est donc difficile de savoir à quoi s'attendre à l'avance, vous devez adapter vos scripts à un appareil particulier. BusyBox est l'implémentation à faible encombrement la plus courante des utilitaires sh et assortis; un autre environnement que vous pourriez rencontrer est l'environnement shell extrêmement réduit d'Android (les versions ultérieures sont moins anémiques).

Les systèmes Linux non intégrés ont presque toujours un tiret ou un bash as /bin/sh. Dash est un petit shell rapide qui n'implémente guère plus que les fonctionnalités POSIX. Bash est un shell plus grand avec plus de fonctionnalités.

Les systèmes Linux non intégrés ont presque toujours Bash installé en tant que /bin/bash. Par conséquent, pour la portabilité sur les systèmes Linux non intégrés, vous pouvez supposer que bash est disponible. Parmi les fonctionnalités supplémentaires utiles de bash, il y a les tableaux, la possibilité de gérer facilement les fichiers à points, la pipestatusvariable pour obtenir le statut de retour de toutes les commandes dans un pipeline, des opérateurs de comparaison supplémentaires pour les temps de fichier et (dans les versions récentes) la correspondance des expressions régulières .

L'une des caractéristiques de la programmation shell est que vous n'utilisez pas seulement le shprogramme, vous utilisez également un certain nombre d' utilitaires . La plupart des utilitaires de manipulation de fichiers et de traitement de texte sous Linux sont les coreutils GNU (sur les systèmes embarqués, ils proviennent généralement de BusyBox).

Si vous avez besoin de portabilité au-delà de Linux, votre meilleur pari est de vous en tenir à POSIX. D'autres versions d'Unix peuvent ne pas avoir bash installé (bash fait partie de l'installation standard sur OSX, mais un paquet facultatif sur * BSD et la plupart des unités commerciales). Presque toutes les variantes Unix autres que Linux et OSX (c'est-à-dire * BSD et les unités commerciales) ont une version du shell Korn , au moins pdksh . De nombreuses extensions pratiques de bash proviennent de ksh, il peut donc être utile d'écrire des scripts pouvant s'exécuter sous les deux, mais détecter où bash ou ksh se trouve sur un système inconnu peut être un peu pénible.

La coquille ne peut pas tout faire. Si vous avez besoin d'un langage plus sophistiqué, les deux choix les plus courants sont Perl et Python (tout le reste est loin derrière en tant que langage de script Unix). Perl est le langage de script traditionnel, et peu de systèmes Linux non intégrés en manquent, mais Python gagne du terrain (stimulé en partie en étant le langage de script recommandé pour Ubuntu). Dans le monde non Linux, Perl fait partie de l'installation de base sur OSX et OpenBSD; il est facultatif mais très couramment installé sur FreeBSD, et facultatif mais souvent installé sur NetBSD.


1
"boosté en partie par ..." Cela et étant tout sauf nécessaire dans les systèmes Fedora et RHEL.
Ignacio Vazquez-Abrams

Plutôt d'accord avec tout cela. Juste quelques accents différents: * certaines distributions sont basées sur BusyBox mais pas nécessairement intégrées (j'en utilise une, Alpine). ( D' accord, la réponse ne dit « presque toujours ».) * Sont BSDs une grande classe de type Unix comme les systèmes où vous ne pouvez pas assumer bash par défaut. * dash peut faire presque tout ce que bash peut faire, il demande parfois plus de soin. * Si vous avez besoin d'un langage plus sophistiqué, oui Perl et Python sont les choix les plus courants, mais awk est encore plus omniprésent et convient à de nombreuses fins. Il est également généralement sous-estimé. Mais il est plus léger que Perl et Python.
dubiousjim

2
Un avertissement juste, cependant - FreeBSD a supprimé Perl de son installation par défaut il y a quelque temps. En dehors de cela, je ne connais aucune autre distribution qui n'a pas Perl dans son installation de base.
TC1

@ TC1 Perl était toujours facultatif sur NetBSD. C'est dans le système de base sur OpenBSD.
Gilles 'SO- arrête d'être méchant'

@dubiousjim Seuls Linux (non embarqué, ou une assez bonne approximation en pratique) et OSX ont bash dans leur installation par défaut; * BSD a pdksh ou mksh, et les unités commerciales ont ATT ksh.
Gilles 'SO- arrête d'être méchant'

11

Dans l'ordre de disponibilité:

  1. sh, mais respectez les installations spécifiées par POSIX.
  2. bash, mais n'oubliez pas de le spécifier explicitement dans le shebang ou vous pourriez obtenir un tiret à la place.
  3. Python. Presque tout le monde l'utilise.
  4. Perl. Mais vous pouvez l'écrire.

Après cela, personne ne s'en soucie vraiment car il n'y a pas grand-chose que vous ne pouvez pas faire avec juste ceux-là.


10
Je mettrais PERL avant python, il est installé par défaut dans la plupart des systèmes Linux.
terdon

4
Perl est n ° 3. Et vous pouvez l'écrire, bonus! :)
Warren Young

2
Je suis d'accord avec @ignacio perl est n ° 4 et python est n ° 3. La raison est évidente. Je pense que Python est une évolution de Perl.
bagavadhar

5
@ashwin: non, python n'est pas une évolution, ni même comme, de perl. perl est un langage de sysadmins pour sysadmins. python est un langage des programmeurs pour les programmeurs. Cette différence est cruciale. Ils ont tous deux leur utilité et bien qu'il puisse y avoir beaucoup de chevauchements dans les cas d'utilisation, pour certaines tâches, perl est le meilleur choix, et pour d'autres, python est clairement supérieur.
cas

1
Ruby et PHP ont été inspirés par Perl. Python est le résultat d'une expérience physique dans laquelle ils ont créé des anti-Perls dans un supercollider. (Je n'ai rien contre Python. Avantages et inconvénients, avantages et inconvénients.)
Warren Young

4

D'ordinaire, je dirais sh... mais puisque vous avez spécifié Linux, je dirai bash- il est garanti d'être sur tous les systèmes Linux autour (enfin, à l'exception des obscurs pédants minuscules qui fétichisent le minimalisme :).

Si vous n'avez pas à vous soucier de la portabilité non-linux (et si vous n'avez pas besoin de fonctionner sur de minuscules distributions ou dans des appareils Linux embarqués comme des routeurs en plastique), vous pouvez également utiliser les améliorations importantes qui il offre sur plaine sh. Sinon, utilisez sh.

Après bash(et sh), le prochain langage de script le plus "universel" pour Linux serait un dialecte de awk- généralement soit mawkou gawk. Si vous vous en tenez à un awk simple et évitez les gawkismes, votre script devrait fonctionner correctement sur presque tous les systèmes Linux (il peut manquer sur de minuscules distributions ou des périphériques intégrés). La plupart des systèmes Linux auront les deux mawket seront gawkdisponibles, mais sur certaines distributions (debian, par exemple) mawkest installé par défaut et vous devez vous installer gawksi vous le souhaitez.

Le prochain serait perl. AFAIK, le langage Perl de base est installé par défaut sur toutes les distributions Linux courantes, ce qui en fait un bon choix. Encore plus heureusement, il y a très peu d'incompatibilité de version avec les versions de perl5 (bien que perl 5.12 ou il aurait pu être 5.14 ait finalement réussi à supprimer certaines fonctionnalités obscures qui étaient obsolètes depuis environ 15 ans ... amplement d'avertissement de ne pas les utiliser) donc à moins que votre style de codage ne soit vraiment bizarre et que vous n'aimiez ignorer plus d'une décennie d'avertissements "ne faites pas ça", vos scripts perl fonctionneront très bien presque n'importe où. Le langage est robuste et puissant et peut tout faire awket sedpeut faire plus encore. Avec un petit effort, il peut faire les chosesshest traditionnellement bon aussi (par exemple, exécuter des commandes externes et utiliser / diriger la sortie). Les bibliothèques Perl standard sont également assez complètes - couvrant plus que les bases.

Le seul inconvénient de perl est qu'il existe également une énorme bibliothèque de modules CPAN pour faire à peu près tout ce que vous pouvez penser (et bien d'autres qui ne vous viendront jamais à l'esprit) - et tous ne seront pas disponibles sur tous les systèmes avec perl . Ils sont généralement de très haute qualité, il est donc facile de prendre l'habitude de simplement les utiliser - mais si vous les utilisez, vous devrez vous assurer qu'ils sont installés. De nombreux modules CPAN sont pré-packagés pour Linux, et les autres sont facilement installés avec l'outil cpan (ou dh-make-perlsur debian / ubuntu / etc pour transformer un module CPAN en package .deb)

J'aimerais pouvoir dire pythonensuite, mais je ne peux vraiment pas. Il y a beaucoup à aimer à propos de python, mais il n'est pas inclus par défaut sur de nombreux systèmes Linux et, franchement, sa compatibilité de version (à la fois pour python lui-même et pour ses bibliothèques prétendument "standard") est une pagaille complète. Certaines distributions font un excellent effort pour régler le désordre, et d'autres non. Ni l'un ni l'autre n'est aidé par le fait que python est fondamentalement un langage écrit pour les programmeurs par des programmeurs (par opposition aux administrateurs système) et ils ne semblent pas penser que le système sur lequel leur code sera installé est du tout important ... leur code est vraiment super spécial donc ils n'ont pas besoin de se préoccuper de trucs ennuyeux comme l'intégration dans des systèmes existants.

(Ne vous méprenez pas sur mon sarcasme ici - j'aime vraiment le python en tant que langage, je déteste juste le fait que la gestion des versions et des dépendances soit un PITA. des morceaux de code et des correctifs pour obtenir quelque chose de compilé et exécuté sur votre propriétaire * nix)


Je sais que c'est un vieux post, mais la meilleure façon de contourner cela est de spécifier quelle version dans le shebang (par exemple /usr/bin/python2, /usr/bin/python3).
Isiah Meadows

1

Je suggérerais de suivre ksh93 ou même la saveur POSIX et vous pouvez toujours utiliser bash / zsh pour exécuter.

Et la distribution basée sur Debian utilise mawk et non gawk comme awk par défaut. Alors oui, évitez les ajouts de gawk car mawk est beaucoup plus rapide.


0

Pas bash. Écrivez à un sh proche de POSIX comme le tiret ou la cendre. Cela va être le plus universel. Je ne pense pas qu'il y ait autre chose qui soit même un concurrent proche. (Et cela me semble être une question factuelle, pas une "opinion" comme se plaint l'un des commentateurs.)

Si vous avez besoin de quelque chose d'un peu plus puissant que sh (par exemple, si vous voulez de vrais tableaux associatifs), utilisez awk. (Éviter les extensions gawk. Il existe de nombreuses versions de awk, mais il existe un noyau largement partagé.) Cela devrait être disponible presque aussi largement que sh.


1
awk-on-Linux est universellement gawk; Je ne peux penser à aucune distribution ayant une autre variante par défaut.
Ignacio Vazquez-Abrams

5
Quelles variantes de Linux ne prennent pas en charge bash?
Jonathan Leffler

1
bashPeut certainement être installé et exécuté sur (presque) n'importe quelle boîte Linux, mais de nombreux utilisateurs de Debian n'installeront que dashet préfèrent ne pas installer bash.
William Pursell

6
@WilliamPursell Le paquet bash est étiqueté Essential sur Debian (c'est-à-dire que vous devez passer par des cerceaux pour désinstaller, avec de nombreux avertissements que cela va arroser votre système). Bash est à peu près universel sur les systèmes Linux non intégrés.
Gilles 'SO- arrête d'être méchant'

1
@JonathanLeffler: Inversement, ceux intégrés ne peuvent avoir que Busybox.
Escargot mécanique

0

Je dirais que la disponibilité se classerait quelque part dans cet ordre:

  1. sh
  2. awk
  3. Perl (je n'ai pas encore vu un * nix sans lui, y compris les BSD)

Bien que Python ressemble à un bon langage, je n'ai utilisé aucun système d'exploitation fourni avec lui dans une installation de base, bien qu'apparemment Ubuntu le fasse, peut-être?


0

Je pense que les experts ici présents ont déjà fourni d'excellentes suggestions qui devraient vous aider à prendre une décision. La convivialité et la disponibilité des différents obus ont été bien décrites dans les autres articles.

Sur une note différente, si j'étais vous, je considérerais également l'objectif que je veux atteindre avec les scripts. Chaque outil a ses propres avantages et inconvénients. Donc, bien que j'utilise largement Python, je ne l'utilise pas dans tous les cas.

Je peux penser à quelques scénarios et mentionner quelques outils utiles pour eux.

Des fichiers FTP en va-et-vient; les traiter; envoyer des notifications par e-mail; etc

Dans ce cas, il serait préférable de s'en tenir au shell (par exemple, Bash) et d'utiliser les divers utilitaires (par exemple ftp, cronet mail). Il s'agit d'un cas d'utilisation typique dans de nombreuses grandes entreprises.

Traitement rapide du texte

Encore une fois, la coquille. Les services publics comme grep, awk, sed, pasteet d' autres sont très utiles dans ce cas.

Construire

Dans le domaine C / C ++, l'outil universel pour cela est make. Le monde Java préfère Apache ANT.

Déploiement et contrôle à distance

Soit le shell, soit Python. Par exemple, scpet rsync, respectivement, seraient très utiles pour copier le ou les fichiers ou synchroniser les fichiers.

Python, d'autre part, a un module très utile nommé fabric. Cela serait utile pour des opérations plus complexes, par exemple pour copier des fichiers, arrêter un processus, reconstituer le serveur, etc. De plus, Python fournit également un module, pipqui peut résoudre les dépendances spécifiées en téléchargeant et en installant les packages appropriés.

(Notez que les suggestions ci-dessus ne se concentrent pas beaucoup sur les fonctionnalités du shell , mais plutôt sur les différents utilitaires disponibles.)


-1

Perl n'est pas dans la base FreeBSD, NetBSD ou DragonflyBSD, désolé. OpenBSD a Perl dans l'installation de base. OS X est aujourd'hui un UNIX certifié et peut être considéré comme une sorte de variante BSD à un certain niveau et il a Perl, Python et Ruby en base.

De nombreux UNIXen propriétaires n'ont pas Perl dans leur base, par exemple Solaris, AFAIK ni HP-UX ou IBM AIX aussi ...


Votre déclaration concernant Solaris manquant Perl est incorrecte. Perl est un composant central obligatoire de Solaris au moins depuis 2005 (Solaris 10).
jlliagre
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.