curl-wget-Venn-Diagramm

 (daniel.haxx.se)
2 Punkte von GN⁺ 2023-09-05 | 1 Kommentare | Auf WhatsApp teilen
  • wget ist kein direkter Konkurrent von curl, sondern sollte je nach Aufgabe eher als Werkzeug mit teilweise überschneidendem Funktionsumfang betrachtet werden, das auch zusammen mit curl genutzt werden kann
  • Das Auswahlkriterium ist nicht die Vorliebe für ein Tool, sondern ob es besser dazu geeignet ist, die Aufgabe zu erledigen; wenn wget passender ist, sollte man wget verwenden
  • Die technischen Unterschiede und Überschneidungen zwischen curl und wget wurden in einem Venn-Diagramm übersichtlich dargestellt; eine Version in voller Auflösung ist ebenfalls verfügbar
  • Die beiden Projekte stehen nicht in einem Gegeneinander; aus dem curl-Umfeld wurden Codebeiträge zu wget geleistet, und mehrere wget-Maintainer haben ebenfalls zu curl beigetragen
  • Fehler oder Auslassungen im Diagramm können aktualisiert werden; weitere Details finden sich in einem separaten Vergleichsdokument sowie in einer Vergleichstabelle für Download-Tools

Kriterien für die Betrachtung von curl und wget

  • wget ist weniger ein Konkurrent zu curl als vielmehr ein begleitendes Werkzeug
  • Beide Tools überschneiden sich in einigen Funktionen, aber entscheidend ist nicht, auf ein bestimmtes Tool zu bestehen, sondern die Wahl an der zu lösenden Aufgabe auszurichten
  • Wenn wget in einer bestimmten Situation besser geeignet ist, die Aufgabe zu Ende zu bringen, sollte man wget verwenden

Die Unterschiede im Venn-Diagramm

  • Um die technischen Unterschiede und einige Gemeinsamkeiten zwischen curl und wget visuell zu zeigen, wurde ein Venn-Diagramm erstellt
  • Durch Anklicken des Diagrammbildes lässt sich die Version in voller Auflösung anzeigen
  • Es wird darum gebeten, auf Fehler oder fehlende Punkte hinzuweisen; bei Bedarf kann das Diagramm aktualisiert werden

Zusammenarbeit zwischen den Projekten

  • Aus dem curl-Umfeld wurden bereits Codebeiträge zu wget geleistet
  • Mehrere wget-Maintainer haben ebenfalls zu curl beigetragen
  • Die Beziehung zwischen den beiden Projekten ist eher von Zusammenarbeit als von Konkurrenz oder Gegnerschaft geprägt

Weitere sehenswerte Vergleichsmaterialien

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2023-09-05
Hacker-News-Kommentare

  • Auf die Wget-Seite gehören meiner Meinung nach mindestens vernünftige Defaults, Fortsetzen abgebrochener Downloads und Wiederholen bei Fehlern
    Kürzlich musste ich ein Skript schreiben, das über eine instabile Verbindung sehr große Dateien herunterlädt, und unter den Ingenieuren galt als allgemeine Meinung, dass man dafür Wget verwenden sollte
    Ich habe auch curl ausprobiert, aber im Default-Zustand konnte es weder Downloads fortsetzen noch erneut versuchen; ich musste das Manual lesen und mehrere Optionen und Argumente angeben. Meinem Gefühl nach sollte dieses Verhalten standardmäßig aktiv sein
    Bei Wget reichte die eine Option --continue, um das Fortsetzen in allen Situationen, einschließlich nach Abstürzen, zu aktivieren; außerdem steht schon in der Einführung des Manuals, es sei darauf ausgelegt, robust in langsamen oder instabilen Netzwerken zu funktionieren, und versuche nach einem fehlgeschlagenen Download so lange weiter, bis die ganze Datei heruntergeladen ist
    Mit curl kann man sicher ebenfalls alle Optionen so setzen, dass es bei schlechten Verbindungen zuverlässig arbeitet, aber bei Wget scheint dieses Standardverhalten bereits aktiv zu sein, sodass ich darauf vertraue, dass es auch in Fehlersituationen, die ich nicht selbst testen konnte, wie erwartet funktioniert. Selbst wenn das HTTP-Protokoll aktualisiert wird, wird ein neues Wget dies wahrscheinlich standardmäßig unterstützen; bei curl könnte dagegen ein neuer Schalter nötig sein, um das verbesserte Verhalten zu aktivieren, und den kann man nach dem Produkt-Release nicht mehr hinzufügen
    Für mich ist curl ein hervorragendes und äußerst vielseitiges Low-Level-Tool, und auch das CLI spiegelt diesen Charakter wider; für Alltagsaufgaben bevorzuge ich aber Wget, weil es im Default-Zustand viel besser funktioniert. Auch das Manual lässt sich schneller überfliegen, vermutlich weil es nicht all die hier erwähnten obskuren Protokolle unterstützt

    • Vernünftigen Defaults stimme ich zu
      Allein dass wget url eine URL herunterlädt und speichert, macht Wget meiner Ansicht nach für die Nutzung auf der Kommandozeile zum Gewinner
    • curl hat genau diese Funktionen ebenfalls. Fortsetzen geht mit dem Flag -C, Wiederholen mit --retry
      Persönlich finde ich die Defaults von curl ziemlich vernünftig, und bei einem Tool wie curl möchte ich keines von beidem standardmäßig aktiviert haben
    • Zu Wget sollte man auch -i hinzufügen, womit es URLs aus einer Datei lesen kann
      Besonders wget -i - ist sehr nützlich in Pipelines, weil es von der Standardeingabe liest
      curl kann das meines Wissens nicht. Üblicherweise heißt es dann, man solle xargs verwenden, aber das wartet, bis alle URLs angekommen sind, und startet dann curl; damit gibt man die Parallelität zwischen dem URL-erzeugenden Befehl und dem Download-Befehl auf, was es als Ersatz nur bedingt geeignet macht
    • Beide Tools haben ihren jeweiligen Einsatzzweck. Mit dem Aufkommen von großen Sprachmodellen wie ChatGPT ist es meiner Meinung nach viel einfacher geworden, für jedes Tool den passenden Kommandozeilen-Zauberspruch zu bekommen
      Selbst wenn man früher das Manual gelesen hat, ist es nicht leicht, sich genau an das gewünschte Flag zu erinnern; eine generierte Kommandozeile zu prüfen ist meist weniger Aufwand, als sie beim Lesen des Manuals von Grund auf zusammenzubauen
      Im modernen Web ist es manchmal einfacher, in selbst geschriebenen Skripten Tools wie Puppeteer zu verwenden. Das gilt besonders, wenn die Website, mit der man interagiert, stark auf JavaScript setzt
    • Dass der URL-Parser von curl viel strenger ist als der von wget, stört mich persönlich ebenfalls
      Zum Beispiel führt $ curl -sSLOJ 'example.com/file name.txt' zu dem Fehler curl: (3) URL using bad/illegal format or missing URL, und $ curl -sSLOJ 'example.com/file%20name.txt' erzeugt eine Datei namens file%20name.txt
      Wget hingegen erzeugt ohne zusätzliche Flags bei beiden URLs eine Datei namens "file name.txt". Allerdings liefert diese Beispiel-URL 404, daher müsste man bei wget streng genommen auch --content-on-error anhängen

  • Für viele dürfte der zentrale Unterschied wahrscheinlich der zwischen einem Tool, das standardmäßig auf die Standardausgabe schreibt, und einem Tool, das standardmäßig eine Datei erzeugt, sein

    • Oder einem Tool, das man standardmäßig nach sh pipen kann ;-)

  • Für mich ist die entscheidende Funktion von Wget, dass es Dateien grundsätzlich unter einem aus der URL abgeleiteten Dateinamen herunterlädt
    Wenn man wget url://to/file.htm ausführt, entsteht im aktuellen Arbeitsverzeichnis eine Datei namens "file.htm"
    Mit curl muss man etwas wie curl url://to/file.htm > file.htm schreiben oder eine andere, weniger bequeme Beschwörungsformel verwenden

    • curl -O
      https://curl.se/docs/manpage.html#-O
    • Stimmt schon, aber es gibt Fälle wie wget "url://to/file.htm?uid=foo&q=bar&rnd=4"
    • Ich habe das immer als Fehlfunktion von Wget betrachtet. Wegen des allgemeinen Prinzips, dass ein Kommandozeilen-Utility sein Hauptergebnis auf die Standardausgabe schreiben sollte, sofern nichts anderes angegeben ist
    • curl -O ist bequemer
      Wenn man dieses „entscheidende Feature“ auf cat überträgt, würde aus cat file.html ein cat file.html > file.html. Wenn man dann tatsächlich ausgeben statt kopieren will, müsste man etwas wie cat file.html -o - schreiben; insofern bin ich froh, dass curl diese Funktion nicht hat

  • Daniel Stenberg gehört zu der seltenen Art von Entwicklern, die Herz und Seele in ihre Schöpfung stecken
    In der heutigen Big Tech wirken schattenhafte Entwickler wie austauschbare Zahnräder in einer Geldmaschine; diese Eigenschaft scheint immer mehr zu verschwinden
    Er scheint curl wie seine Spur zu behandeln, die er in der IT-Welt hinterlässt

    • Freie Software ist voll von solchen Menschen. Deshalb nutze ich freie Software, selbst wenn sie technisch unterlegen ist
      Wobei sie heute natürlich oft tatsächlich technisch besser ist, was die Entscheidung leichter macht
    • Wenn man in einer Firma arbeitet, steckt man vielleicht nicht sein Herz in die eigene Schöpfung; aber wenn jemand ein beliebtes persönliches Projekt hat, das viel Geld einbringt, würde wohl jeder entsprechend engagiert sein

  • Dieser Vergleich scheint etwas veraltet zu sein. Zum Beispiel fehlen auf der Wget-Seite des Diagramms die folgenden beiden Punkte
    HTTP PUT geht mit wget --method=PUT --body-data=, und Proxy sowie HTTPS gehen ebenfalls etwa mit wget --use-proxy=on --https_proxy=[https://example.com](<https://example.com>;)
    curl hat durchgehend mehr Optionen und mehr Flexibilität, aber unter den vielen Punkten auf der rechten Seite des Venn-Diagramms gibt es einige, die Wget zumindest in gewissem Umfang ebenfalls kann

    • Laut Manpage scheint es auch FTP-Unterstützung zu geben

  • Wow, ich wusste nicht, dass curl so viele Protokolle unterstützt. Trotzdem ist die kleine Schnittmenge wahrscheinlich der Teil, den über 90 % der curl-/Wget-Nutzer tatsächlich verwenden
    Aus Entwicklersicht ist der überlappende Bereich nicht besonders groß, aus Nutzersicht kann er aber deutlich größer wirken

  • Der beste Teil des Artikels war für mich dieser Satz
    „Ich habe Code zu wget beigetragen. Mehrere wget-Maintainer haben auch zu curl beigetragen. Wir sind alle Freunde.“

  • Der von Daniel Stenberg erstellte Vergleich ist ebenfalls Pflichtlektüre
    https://daniel.haxx.se/docs/curl-vs-wget.html

    • Auch dieser neue Vergleich stammt von Daniel Stenberg und wird auf derselben Domain gehostet, steht aber in seinem Blog und nicht in der curl-Dokumentation

  • Früher habe ich Wget verwendet, wenn ich eine Website spiegeln wollte. Wget ist ein spezialisiertes Tool
    curl ist eine universelle Request-Bibliothek mit CLI-Frontend und wird auch in andere Programme eingebettet oder wie eine Standardbibliotheks-API etwa in PHP verwendet

    • Persönlich mag ich httrack fürs Spiegeln, aber Wget hat eine href/src-Umwandlungsfunktion, weshalb es für bestimmte Ziele gelegentlich besser passt

  • Die häufigste Nutzung dürfte im überlappenden Bereich der beiden liegen. Deshalb würde ich gern ein Venn-Diagramm sehen, das zeigt, auf welchen Betriebssystemen und Docker-Images welches Tool standardmäßig installiert ist