Quelles sont les différences entre Perl, Python, AWK et sed? [fermé]


253

je veux juste savoir quelles sont les principales différences entre eux? et la puissance de chaque langue (où il vaut mieux l'utiliser).

Edit: ce n'est pas "vs" comme sujet, juste des informations.


142
Ce type de questions dites non constructives est vraiment utile.
Steam

10
Bien sûr, un onglet sur la première page pour les trouver serait pratique ...

Pour l'utilité de python sur la ligne de commande, voir pyp
Neil McGuigan

Réponses:


550

Par ordre d'apparition, les langues sont sed, awk, perl, python.

Le sedprogramme est un éditeur de flux et est conçu pour appliquer les actions d'un script à chaque ligne (ou, plus généralement, à des plages de lignes spécifiées) du ou des fichiers d'entrée. Son langage est basé sur edl'éditeur Unix, et bien qu'il ait des conditions et ainsi de suite, il est difficile de travailler avec des tâches complexes. Vous pouvez faire des miracles mineurs avec cela - mais à un prix pour les cheveux sur votre tête. Cependant, il est probablement le plus rapide des programmes lors de la tentative de tâches dans son domaine de compétence. (Il a les expressions régulières les moins puissantes des programmes discutés - adéquates à de nombreuses fins, mais certainement pas PCRE - Expressions régulières compatibles Perl)

Le awkprogramme (nom des initiales de ses auteurs - Aho, Weinberger et Kernighan) est un outil initialement utilisé pour formater les rapports. Il peut être utilisé comme une soupe sed; dans ses versions les plus récentes, il est complet sur le plan informatique. Il utilise une idée intéressante - le programme est basé sur des «motifs assortis» et des «actions prises lorsque le motif correspond». Les modèles sont assez puissants (Expressions régulières étendues). Le langage utilisé pour les actions est similaire à C. L'une des principales caractéristiques awkest qu'il divise automatiquement l'entrée en enregistrements et chaque enregistrement en champs.

Perl a été écrit en partie comme un tueur d'awk et un tueur de sed. Deux des programmes fournis avec lui sont a2pet s2ppour convertir des awkscripts et des sedscripts en Perl. Perl est l'un des premiers de la prochaine génération de langages de script (Tcl / Tk peut probablement revendiquer la primauté). Il possède une puissante gestion intégrée des expressions régulières avec un langage beaucoup plus puissant. Il donne accès à presque tous les appels système et a l'extensibilité des modules CPAN. (Ni l'un awkni l' autre sedn'est extensible.) L'une des devises de Perl est "TMTOWTDI - Il y a plus d'une façon de le faire" (prononcé "tim-toady"). Perl a des «objets», mais il s'agit plus d'un module complémentaire que d'une partie fondamentale du langage.

Python a été écrit en dernier, et probablement en partie en réaction à Perl. Il a quelques idées syntaxiques intéressantes (indentation pour indiquer les niveaux - pas d'accolades ou d'équivalents). Il est plus fondamentalement orienté objet que Perl; il est tout aussi extensible que Perl.

OK - quand les utiliser?

  • Sed - lorsque vous devez effectuer de simples transformations de texte sur des fichiers.
  • Awk - lorsque vous n'avez besoin que d'un formatage simple et d'un résumé ou d'une transformation des données.
  • Perl - pour presque toutes les tâches, mais surtout lorsque la tâche nécessite des expressions régulières complexes.
  • Python - pour les mêmes tâches que vous pourriez utiliser Perl.

Je ne suis au courant de rien que Perl puisse faire que Python ne puisse faire, ni vice versa. Le choix entre les deux dépendrait d'autres facteurs. J'ai appris Perl avant qu'il n'y ait un Python, donc j'ai tendance à l'utiliser. Python a une syntaxe moins accrétée et est généralement un peu plus simple à apprendre. Perl 6, lorsqu'il sera disponible, sera un développement fascinant.

(Notez que les `` aperçus '' de Perl et Python, en particulier, sont malheureusement incomplets; des livres entiers pourraient être écrits sur le sujet.)


82
Un article ++++, relirait!
Robert Gamble

24
génial surtout "quand utiliser chaque" partie
Khaled Al Hourani

6
notez que le zen de python est fondamentalement l'antithèse de TMTOWTDI donc je dirais que cela pourrait être une réaction à perl. iirc TCL était légèrement après perl et est également assez réactionnaire contre perl, bien que la réaction de TCL soit dans la complexité de la syntaxe et du langage, pas dans les façons de faire les choses
jk.

7
Quelles que soient les intentions originales, il est clair que le développement ultérieur de Python et la communauté python ont préféré la lisibilité et la cohérence à la syntaxe plus flexible mais concise de Perl. Excellent post Jonathan
Martin Beckett

4
@blasto: Pour ETL, je la priorité awksur l' sedapprentissage (si les deux ont encore leurs utilisations). Quant à la taille de la tâche: sedest à son meilleur quand il traite une ligne à la fois, sans stockage de ligne à ligne. awkest souvent utilisé pour construire des tableaux associatifs avec des données accumulées à partir de toutes les sources; il utilise plus de mémoire et est donc beaucoup plus susceptible de rencontrer des problèmes avec des ensembles de données volumineux sed. Je n'en ai pas entendu parler tsawkavant que vous ne vous y liez. J'ai tendance à me rabattre sur Perl (mais vous pourriez faire mieux avec Python) quand une tâche est trop lourde awk.
Jonathan Leffler

91

Après avoir maîtrisé quelques dizaines de langues, vous en avez marre de gens comme S. Lott (voir sa réponse controversée à cette question, près de la moitié des votes négatifs (+ 45 / -22) six ans après avoir répondu).

Sed est le meilleur outil pour les pipelines en ligne de commande extrêmement simples. Entre les mains d'un maître sed, il convient pour des pièces uniques de complexité arbitraire, mais il ne doit pas être utilisé dans le code de production, sauf dans les pipelines de substitution très simples. Des trucs comme 's / this / that /.'

Gawk (GNU awk) est de loin le meilleur choix pour le reformatage de données complexes lorsqu'il n'y a qu'une seule source d'entrée et une seule sortie (ou plusieurs sorties écrites séquentiellement). Puisqu'une grande partie du travail réel est conforme à cette description et qu'un bon programmeur peut apprendre le gawk en deux heures, c'est le meilleur choix. Sur cette planète, plus simple et plus rapide, c'est mieux!

Perl ou Python sont bien meilleurs que n'importe quelle version de awk ou sed lorsque vous avez des scénarios d'entrée / sortie très complexes. Plus le problème est complexe, mieux vous utilisez python, du point de vue de la maintenance et de la lisibilité. Notez, cependant, qu'un bon programmeur peut écrire du code lisible dans n'importe quel langage, et un mauvais programmeur peut écrire de la merde non maintenable dans n'importe quel langage utile, donc le choix de perl ou de python peut être laissé aux préférences du programmeur en toute sécurité si ledit programmeur est habile et intelligent.


9
100% d'accord. Connaître le plus, sinon tous les outils ET quand les utiliser est ce qui distingue un bon technicien d'un médiocre.
ata

6
J'ajouterai qu'une autre raison de choisir Python ou Perl au lieu de awk est lorsque vos exigences de transformation impliquent une validation ou une logique complexe pour laquelle une autre langue a un module robuste existant. Pensez à ce qu'il faudrait pour gérer correctement les adresses e-mail ou les rues dans awk et vous verrez ce que je veux dire: perl et python ont des bibliothèques qui rendent les choses comme ça triviales, dans awk celles-ci sont rares ou indisponibles.
sorpigal

3
En fait, Perl a été conçu pour englober Sed et Awk; Je trouve plus facile de simplement l'écrire en Perl, plutôt que d'apprendre Sed ou Awk.
Brad Gilbert

@BradGilbert: comme je viens de le mentionner dans la réponse du haut, une mise en garde de Perl (& Python, ruby, etc.) sur awk est que certaines expressions rationnelles sont reaaaaaaaaaaally légèrement plus lentes dans l'ancienne: swtch.com/~rsc/regexp/regexp1.html
Olivier Dulac

1
@OlivierDulac Oui qui montre un cas pathologique. Si vous changez de a?ⁿaⁿen a??ⁿaⁿpuis exécutez cela en Perl 5 avec 1 000 000, il s'exécute en moins de deux secondes. time perl -E '$x=1_000_000;$_="a"x$x;$m=("a??"x$x).("a"x$x);say $_=~$m'Si vous exécutez la version naïve, cela prend plus de deux secondes pour une valeur de seulement 25. La chose que vous devez réaliser est que Perl a plus de fonctionnalités d'expression régulière que celles plus rapides, y compris vous permettant d'avoir du code Perl à l'intérieur de l'expression régulière qui modifie ce à quoi il correspond. . Vous pouvez implémenter un module qui échange le intégré pour l'un de ces autres si vous le souhaitez.
Brad Gilbert

21

Je n'appellerais pas sed un langage de programmation à part entière, c'est un éditeur de flux avec des constructions de langage visant à éditer des fichiers texte par programmation.

Awk est un peu plus un langage à usage général mais il est toujours mieux adapté au traitement de texte.

Perl et Python sont des langages de programmation polyvalents à part entière. Perl a ses racines dans le traitement de texte et a un certain nombre de constructions de type awk (il y a même un script awk-to-perl flottant sur le net). Il existe de nombreuses différences entre Perl et Python, votre meilleur pari est probablement de lire les résumés des deux langues sur quelque chose comme Wikipedia pour avoir une bonne compréhension de ce qu'ils sont.


2
J'ai vu une implémentation sed de Sokoban, ce qui impliquerait l'exhaustivité de Turing. Cependant, cela peut également être dit de sendmail.cf et TeX.
ConcernedOfTunbridgeWells

7
J'ai déjà travaillé avec un gars qui a écrit PostScript pour transformer une imprimante laser en routeur.
Sam Kington

10
@Sam: Wow! Je ne savais pas que le laser d'une imprimante pouvait être monté suffisamment pour couper du bois! Oh, désolé, mauvais type de routeur.
pause jusqu'à nouvel ordre.

2
sed, pas une langue à part entière? Eh bien, ce n'est pas tout à fait vrai, car sed est en train de se terminer ;)
bernard paulus

1
J'ai vu une implémentation du quatrième langage dans awk. (Puisque awk peut être considéré comme un analyseur à part entière, il est plutôt simple d'y implémenter un interpréteur).
Tatjana Heuser

19

Premièrement, il y a deux choses indépendantes dans la liste "Perl, Python awk et sed".

Thing 1 - outils de manipulation de texte simplistes.

  • sed. Il a une portée de travail fixe et relativement simple définie par l'idée de lire et d'examiner chaque ligne d'un fichier. sed n'est pas conçu pour être particulièrement lisible. Il est conçu pour être très petit et très efficace sur de très petits serveurs Unix.

  • awk. Son périmètre de travail est un peu moins fixe et moins simple. Cependant, la boucle principale d'un programme awk est définie par la lecture implicite des lignes d'un fichier source.

Ce ne sont pas des langages de programmation "complets". Bien que vous puissiez - avec un peu de travail - écrire des programmes assez sophistiqués dans awk, cela devient rapidement compliqué et difficile à lire.

Thing 2 - langages de programmation à usage général. Ceux-ci ont une grande variété de types d'instructions, de nombreuses structures de données intégrées et aucune hypothèse ou raccourci câblé à proprement parler.

  • Perl.

  • Python.

Quand les utiliser.

  • sed. Jamais. Il n'a vraiment aucune valeur à l'ère moderne des ordinateurs avec plus de 32 Ko de mémoire. Perl ou Python font les mêmes choses plus clairement.

  • awk. Jamais. Comme sed, il reflète une époque antérieure de l'informatique. Plutôt que de conserver cette langue (en plus de toutes les autres requises pour un système réussi), il est plus agréable de tout simplement faire dans une langue agréable.

  • Perl. Tout problème de programmation de toute nature. Si vous aimez la syntaxe libre-pensée, où il existe de nombreuses façons de faire la même chose, Perl est amusant.

  • Python. Tout problème de programmation de toute nature. Si vous aimez la syntaxe assez limitée, où il y a moins de choix, moins de subtilité et (peut-être) plus de clarté. La nature orientée objet de Python le rend plus adapté aux problèmes complexes et volumineux.

Contexte - Je ne dénonce pas sed et awk par ignorance. J'ai appris awk il y a plus de 20 ans. A fait beaucoup de choses avec elle; utilisé pour l'enseigner comme une compétence de base unix. J'ai appris Perl il y a environ 15 ans. A fait beaucoup de choses sophistiquées avec. J'ai laissé les deux derrière parce que je peux faire les mêmes choses en Python - et c'est plus simple et plus clair.

Il y a deux problèmes graves avec sed et awk, ni l'un ni l'autre de leur âge.

  1. Le caractère incomplet de leur mise en œuvre. Tout ce que sed et awk font peut être fait en Python ou Perl, souvent plus simplement et parfois plus vite aussi. Un pipeline shell présente certains avantages en termes de performances en raison de son multi-traitement. Python propose un subprocessmodule pour me permettre de récupérer ces avantages.

  2. La nécessité d'apprendre encore une autre langue. En faisant des choses en Python (ou Perl), votre implémentation dépend de moins de langues, avec une augmentation résultante de la clarté.


66
Quelques arguments assez fatals contre awk / sed. La clé à molette n'a pas supplanté la clé ouverte pour la même raison que sed et awk sont toujours livrés. Parfois, l'outil simple est le meilleur pour le travail. J'écris beaucoup de perl, mais pour une simple chaîne de commandes piped, awk / sed sont plus rapides que perl -e
RET

27
Vous ne pouvez pas supposer la disponibilité d'autre chose que sh, sed et awk sur la plupart des systèmes Unix non linux. Si vous voulez que quelque chose fonctionne sur une installation prête à l'emploi de Solaris, HP / UX ou AIX, vous êtes coincé avec sed et awk.
ConcernedOfTunbridgeWells

27
La moitié de mes scripts shell utilisent sed ou awk. Ils sont loin d'être morts. Python est mon langage de script préféré, mais parfois sed et awk sont le meilleur outil pour le travail. Ce n'est pas parce qu'ils sont utilisés depuis de nombreuses années qu'ils sont obsolètes.
Jeremy Cantrell

16
@ S.Lott: Je ne dis pas que quiconque devrait essayer de créer une application web en awk, mais dire qu'ils ne devraient jamais être utilisés est un peu scandaleux. Pour un simple s & r et / ou un tweak (en particulier dans un fichier texte délimité), perl -e ou python -c ne sera jamais aussi efficace qu'un one-liner sed / awk.
RET

25
Je n'aime pas les réponses comme ça. Sed et awk sont faciles à comprendre en quelques heures et beaucoup plus légers et largement disponibles qu'une langue à part entière. La programmation de Shell est toujours aussi pertinente, disant que "JAMAIS" utiliser tel ou tel outil est simplement retardé. Mais cette idée retardée n'était-elle pas l'un des fondements sur lesquels Perl a émergé? Oh bien--
ata

14

Quand les utiliser: awk - jamais - S. Lott.

Je pense que S. Lott a légèrement raté le cap avec cette recommandation. Le fait est que, sous Linux et les autres environnements UNIX, awk est un outil utile à utiliser avec bash, sh et ksh pour des traitements de texte rapides. L'idée du script lui-même est de résoudre votre problème en collant ensemble cet outil, cet outil. Par conséquent, dans les scripts d'administration, il est courant d'avoir ls, grep, |, awk, time, ps, etc. Chacun est un outil que le scripteur combine comme un constructeur brique par brique pour terminer le bâtiment (pour résoudre le problème actuel) .

Par exemple, je suis un membre de l'équipe qui gère les fournitures d'équipement de paintballdotcom. Ce site de commerce électronique est basé sur la pile LAMP. Pour le traitement automatisé et la normalisation des flux de données de divers fournisseurs dans la base de données principale, nous utilisons et maintenons un mélange diversifié de scripts, y compris bash, perl, php, et même attendons. Chacun a ses points forts basés sur les modules et l'API disponibles. Dans les scripts bash, nous effectuons une correspondance rapide des modèles et des actions appropriées sur les modèles selon les besoins en utilisant awk sans avoir besoin de passer à PERL. Une chose que je voudrais également souligner, qui n'a pas été soulignée dans le fil, est qu'un bon nombre de ces scripts ont été achetés ou obtenus à partir de l'open source. Si le script est venu en Perl, nous le maintenons en Perl; si le script est venu comme Php, nous le maintenons comme Php; s'il est venu comme bash, nous le maintenons comme bash;


7
c'est S.Lott qui a écrit cette réponse que vous avez citée, pas brian d foy ...
plusplus

5
comme note latérale sur cette réponse assez ancienne: ne jamais analyser la sortie de ls, utilisez plutôt glob. lis ça.
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.