Diagramme de Venn de curl et wget

 (daniel.haxx.se)
2 points par GN⁺ 2023-09-05 | 1 commentaires | Partager sur WhatsApp
  • wget ne doit pas être vu comme un concurrent direct de curl, mais comme un outil aux fonctionnalités partiellement chevauchantes qui peut être utilisé avec lui selon la tâche
  • Le critère de choix n’est pas la préférence pour un outil, mais sa capacité à mieux permettre d’achever la tâche ; si wget est plus adapté, il faut utiliser wget
  • Les différences techniques et les zones de recouvrement entre curl et wget ont été résumées d’un seul coup d’œil dans un diagramme de Venn, avec aussi une image en pleine résolution
  • Les deux projets ne sont pas dans une logique d’opposition : des contributions de code ont été faites de curl vers wget, et plusieurs mainteneurs de wget ont aussi contribué à curl
  • Les erreurs ou omissions du diagramme peuvent être corrigées dans des mises à jour, et il est possible d’aller plus loin avec un document de comparaison séparé et un tableau comparatif des outils de téléchargement

Comment envisager curl et wget

  • wget est plus proche d’un outil complémentaire que d’un concurrent de curl
  • Les deux outils ont certaines fonctionnalités en commun, mais l’essentiel n’est pas de s’obstiner sur un outil précis : il faut choisir en fonction de la tâche à résoudre
  • Si, dans une situation donnée, wget est plus approprié pour mener la tâche à son terme, il vaut mieux utiliser wget

Les différences résumées dans un diagramme de Venn

  • Un diagramme de Venn a été créé pour montrer visuellement les différences techniques entre curl et wget, ainsi que certains points communs
  • En cliquant sur l’image du diagramme, on peut voir la version en pleine résolution
  • L’auteur demande qu’on lui signale les problèmes ou les éléments manquants, et indique que le diagramme peut être mis à jour si nécessaire

Collaboration entre les projets

  • Des contributions de code ont déjà été faites de curl vers wget
  • Plusieurs mainteneurs de wget ont aussi contribué à curl
  • La relation entre les deux projets relève davantage de la collaboration que de la concurrence ou de l’opposition

Autres ressources de comparaison

À lire aussi

1 commentaires

 
GN⁺ 2023-09-05
Avis sur Hacker News

  • Je pense qu’il faudrait au minimum ajouter côté Wget des valeurs par défaut raisonnables, la reprise de téléchargement et les nouvelles tentatives en cas d’erreur
    Récemment, j’ai dû écrire un script pour télécharger un très gros fichier sur une connexion instable, et l’idée reçue chez les ingénieurs était qu’il fallait utiliser Wget pour ce genre de tâche
    J’ai aussi essayé curl, mais par défaut il ne reprenait pas les téléchargements et ne réessayait pas ; il fallait lire le manuel et préciser plusieurs options et arguments. J’ai l’impression que ce comportement devrait être activé par défaut
    Avec Wget, une seule option, --continue, suffisait pour activer la reprise dans tous les cas, y compris après un plantage, et l’introduction du manuel indique qu’il est conçu pour fonctionner de façon robuste sur des réseaux lents ou instables et que, si un téléchargement échoue, il réessaie jusqu’à obtenir le fichier complet
    On peut sans doute régler toutes les options de curl pour qu’il soit fiable sur une mauvaise connexion, mais Wget semble déjà avoir ce comportement par défaut, ce qui me donne confiance dans le fait qu’il se comportera comme attendu même dans des situations d’erreur que je n’ai pas pu tester. Même si le protocole HTTP évolue, un nouveau Wget aura probablement la prise en charge activée par défaut, alors que curl pourrait nécessiter un nouveau commutateur pour activer le comportement amélioré, impossible à ajouter après la sortie du produit
    Pour moi, curl est un excellent outil bas niveau, très polyvalent, et sa CLI reflète cette nature, mais pour les tâches quotidiennes je préfère Wget, qui fonctionne bien mieux tel quel. Son manuel se parcourt aussi plus vite, probablement parce qu’il ne prend pas en charge tous les protocoles ésotériques mentionnés ici

    • Je suis d’accord sur les valeurs par défaut raisonnables
      Rien que le fait que wget url télécharge et enregistre l’URL fait, à mon avis, gagner Wget pour l’usage en ligne de commande
    • curl a exactement cette fonctionnalité. La reprise se fait avec le drapeau -C, et les nouvelles tentatives avec --retry
      Personnellement, je trouve aussi les valeurs par défaut de curl assez raisonnables, et je ne voudrais pas que l’une ou l’autre de ces deux options soit activée par défaut dans un outil comme curl
    • Il faut aussi ajouter -i, qui permet à Wget de lire les URL depuis un fichier
      En particulier, wget -i - lit depuis l’entrée standard, ce qui est très utile dans les pipelines
      À ma connaissance, curl ne sait pas faire ça. On dit généralement d’utiliser xargs, mais comme il attend que toutes les URL soient arrivées avant de lancer curl, on perd le parallélisme entre la commande qui génère les URL et celle qui les télécharge, ce qui en fait un substitut assez bancal
    • Les deux outils ont chacun leur usage. Avec l’arrivée des grands modèles de langage comme ChatGPT, il est devenu beaucoup plus facile d’obtenir la bonne incantation en ligne de commande, quel que soit l’outil utilisé
      Même si l’on a déjà lu le manuel, il n’est pas facile de se souvenir exactement du bon drapeau, et vérifier une ligne de commande générée demande généralement moins d’effort que de la construire depuis zéro en lisant le manuel
      Sur le Web moderne, il est parfois plus simple d’utiliser des outils comme Puppeteer dans des scripts faits maison, surtout si le site avec lequel on interagit utilise beaucoup JavaScript
    • Le fait que le parseur d’URL de curl soit beaucoup plus strict que celui de wget est aussi quelque chose qui m’agace personnellement
      Par exemple, $ curl -sSLOJ 'example.com/file name.txt' produit l’erreur curl: (3) URL using bad/illegal format or missing URL, et $ curl -sSLOJ 'example.com/file%20name.txt' crée un fichier nommé file%20name.txt
      À l’inverse, wget crée un fichier "file name.txt" depuis les deux URL, sans drapeau supplémentaire. Cela dit, comme cette URL d’exemple renvoie une 404, il faudrait en toute rigueur ajouter --content-on-error à wget

  • Pour beaucoup de gens, la différence essentielle est sans doute entre un outil qui écrit par défaut sur la sortie standard et un outil qui crée par défaut un fichier

    • Ou un outil que l’on peut, par défaut, rediriger vers sh ;-)

  • Pour moi, la fonctionnalité décisive de Wget est qu’il télécharge par défaut dans un fichier au nom déduit de l’URL
    Si l’on exécute wget url://to/file.htm, on obtient un fichier "file.htm" dans le répertoire de travail courant
    Avec curl, il faut écrire quelque chose comme curl url://to/file.htm > file.htm, ou une autre incantation moins pratique

    • curl -O
      https://curl.se/docs/manpage.html#-O
    • Certes, mais il y a des cas comme wget "url://to/file.htm?uid=foo&q=bar&rnd=4"
    • J’ai toujours vu cela comme une mauvaise fonctionnalité de Wget. Selon le principe général, un utilitaire en ligne de commande devrait écrire son résultat principal sur la sortie standard sauf instruction contraire
    • curl -O est plus pratique
      Si l’on transpose cette « fonctionnalité décisive » à cat, cela revient à transformer cat file.html en cat file.html > file.html. Ensuite, quand on veut réellement afficher plutôt que copier, il faudrait écrire quelque chose comme cat file.html -o -; je suis donc content que curl n’ait pas ce comportement

  • Daniel Stenberg fait partie de cette rare catégorie de développeurs qui mettent du cœur et de l’âme dans leur création
    Dans les grandes entreprises tech modernes, les développeurs de l’ombre ressemblent à des rouages remplaçables de machines à faire de l’argent, et cette qualité semble disparaître peu à peu
    Il semble considérer curl comme l’empreinte qu’il laisse dans le monde de l’IT

    • Le logiciel libre est rempli de gens comme ça. C’est pour cela que j’utilise du logiciel libre, même quand il est techniquement inférieur
      Bien sûr, de nos jours, il est souvent réellement meilleur techniquement, ce qui rend le choix plus facile
    • Quand on travaille en entreprise, on ne met pas forcément son cœur dans sa création, mais si l’on a un projet personnel populaire qui rapporte beaucoup d’argent, j’imagine que n’importe qui s’y consacrerait autant

  • Cette comparaison semble un peu datée. Par exemple, côté Wget dans le diagramme, il manque au moins les deux éléments suivants
    HTTP PUT est possible avec wget --method=PUT --body-data=, et les proxys ainsi que HTTPS le sont aussi, par exemple avec wget --use-proxy=on --https_proxy=[https://example.com](<https://example.com>;)
    curl dispose toujours de davantage d’options et de flexibilité, mais parmi les nombreux éléments placés à droite du diagramme de Venn, certains sont aussi faisables dans une certaine mesure avec Wget

    • D’après la page de manuel, il semble aussi y avoir la prise en charge de FTP

  • Waouh, je ne savais pas que curl prenait en charge autant de protocoles. Cela dit, la petite zone d’intersection correspond probablement à ce que plus de 90 % des utilisateurs de curl/Wget utilisent réellement
    Du point de vue d’un développeur, le chevauchement n’est pas très grand, mais du point de vue d’un utilisateur, il peut paraître beaucoup plus important

  • Le meilleur passage de l’article, pour moi, est cette phrase
    « J’ai déjà contribué du code à wget. Plusieurs mainteneurs de wget ont aussi contribué à curl. Nous sommes tous amis. »

  • La comparaison faite par Daniel Stenberg est aussi incontournable
    https://daniel.haxx.se/docs/curl-vs-wget.html

    • Cette nouvelle comparaison est également faite par Daniel Stenberg et hébergée sur le même domaine, mais elle figure sur son blog, pas dans la documentation de curl

  • Avant, quand je voulais miroiter un site Web, j’utilisais Wget. Wget est un outil spécialisé
    curl est une bibliothèque de requêtes généraliste avec un frontend CLI, qui est aussi embarquée dans d’autres programmes ou utilisée comme API de bibliothèque standard, par exemple en PHP

    • Personnellement, j’aime bien httrack pour le mirroring, mais Wget a une fonctionnalité de conversion des href/src qui convient parfois mieux à certains objectifs

  • L’usage le plus courant se situe probablement dans la zone de recouvrement des deux. J’aimerais donc voir un diagramme de Venn montrant sur quels systèmes d’exploitation et images Docker chaque outil est installé par défaut