Zwei Befehlszeilentools, die beide Daten über HTTP abrufen, auf fast jedem Rechner installiert sind, endlos miteinander verglichen und selten sinnvoll voneinander unterschieden werden.
Die zuverlässigste Quelle zum Unterschied ist erfreulicherweise der Vergleich, den der Betreuer von curl selbst veröffentlicht hat – ein Dokument, das einen eigenen Abschnitt darüber enthält, was wget besser kann als curl. Jede der folgenden sachlichen Aussagen lässt sich auf dieses Dokument oder auf die Handbücher der Projekte selbst zurückführen und beruht nicht auf persönlichen Eindrücken, was bei einem Vergleich, der so oft aus dem Gedächtnis geschrieben wird, von Bedeutung ist.
Wir sind Geonode, wir verkaufen Proxys, und die ehrliche Anmerkung ist kurz: Keines der beiden Tools benötigt für den Großteil der Anwendungsfälle, für die sie genutzt werden, einen Proxy. Eine Datei abrufen, eine API aufrufen, prüfen, ob ein Dienst antwortet – für nichts davon ist einer erforderlich. Es gibt einen echten und kaum dokumentierten Unterschied zwischen den beiden Tools hinsichtlich der Proxy-Unterstützung, dem weiter unten ein Abschnitt gewidmet ist. Wenn Sie jedoch hierher gekommen sind, um sich für einen Downloader zu entscheiden, können Sie diesen Abschnitt getrost ignorieren.
Zusammenfassend lässt sich sagen, dass diese Tools nach unterschiedlichen Denkmodellen entwickelt wurden und sich fast jeder oberflächliche Unterschied daraus ergibt. curl verhält sich wie cat – es ruft etwas ab und schreibt es in die Standardausgabe. wget verhält sich wie cp – es ruft etwas ab und schreibt es in eine Datei. Das ist die Sichtweise des Entwicklers, und sobald man das verstanden hat, erscheinen die Standard-Weiterleitungen, die Unterschiede bei den Optionen und die Rekursionsfähigkeit nicht mehr willkürlich.
Die kurze Empfehlung für alle, die sie vor den Details haben möchten: Verwende wget, wenn du Dateien auf der Festplatte haben möchtest, und curl für alles andere.
Der Unterschied in einem Satz
curl funktioniert, wie es der Betreuer formuliert, „wie der traditionelle Unix-Befehl ``cat`
“. wget funktioniert „eher wie ``cp
`“.
Dieser eine Unterschied erklärt das meiste von dem, was nun folgt.
Was das in der Praxis bedeutet:
curl https://example.com/file.txt # prints the contents to your terminal
wget https://example.com/file.txt # saves file.txt to the current directory
Keines der beiden Programme ist falsch. Sie beantworten unterschiedliche Fragen.
Das Design von curl geht davon aus, dass Sie die Daten haben möchten und dass es Ihre Sache ist, was anschließend damit geschieht – sie weiterleiten, analysieren, umleiten oder lesen. Das Schreiben in die Standardausgabe ist die kombinierbare Wahl, und deshalb fügt sich curl ganz natürlich in Shell-Pipelines ein.
Das Design von wget geht davon aus, dass Sie die Datei haben wollen. Es wählt den Dateinamen aus, erstellt die Datei, zeigt einen Fortschrittsbalken an und endet mit einer Datei auf der Festplatte.
Warum die Konsequenzen weitreichender sind, als es den Anschein hat
Sobald die Aufgabe eines Tools darin besteht, „die Datei auf die Festplatte zu bringen“, wird eine ganze Reihe von Verhaltensweisen offensichtlich richtig: Umleitungen verfolgen, weil die Datei verschoben wurde; bei Fehlern erneut versuchen, weil das Ziel die Datei ist und nicht der Versuch; einen unvollständigen Download fortsetzen, weil eine halbe Datei nicht das Ziel ist. wget tut all dies standardmäßig.
Sobald die Aufgabe eines Tools darin besteht, „diese Übertragung durchzuführen und mir das Ergebnis zu liefern“, sehen die korrekten Verhaltensweisen anders aus: Melde, was passiert ist, anstatt für mich zu entscheiden; führe genau das aus, was verlangt wurde, und überlasse dem Aufrufer die weitere Bearbeitung. curl meldet die Umleitung und bricht ab, da das Verfolgen dieser Umleitung nicht das war, was du verlangt hast.
Keine der beiden Standardverhaltensweisen ist besser. Sie entsprechen unterschiedlichen Zwecken, und der Großteil der Frustration, die Nutzer mit beiden Tools erleben, rührt daher, dass sie die Annahmen des jeweils anderen Tools erwarten.
Was curl kann, was wget nicht kann
Aus dem Vergleich des Betreuers – und es handelt sich um eine umfangreiche Liste.
Es ist in erster Linie eine Bibliothek
curl enthält libcurl, das als „stabile API, die von jedem genutzt werden kann“ beschrieben wird. Dies ist der folgenreichste Unterschied und derjenige, der vom Terminal aus am wenigsten sichtbar ist.
libcurl ist in eine enorme Menge an Software eingebettet – Sprachbindungen, Anwendungen, Geräte. Das Befehlszeilentool ist in gewisser Weise eine Demonstration der Bibliothek. wget ist ein Programm; curl ist ein Programm, das auf einer Bibliothek aufbaut, die von anderen Programmen genutzt wird.
Wenn Sie jemals die cURL-Funktionen von PHP oder eine auf libcurl aufbauende HTTP-Sprachbindung verwendet haben, haben Sie curl genutzt, ohne curl auszuführen.
Weitaus mehr Protokolle
Die veröffentlichte Liste ist lang: „FTP(S), GOPHER(S), HTTP(S), SCP, SFTP, TFTP, TELNET, DICT, LDAP(S), MQTT, FILE, POP3(S), IMAP(S), SMB(S), SMTP(S), RTMP, RTSP und WS(S)“.
wget deckt HTTP, HTTPS und FTP ab. Für das Web reicht das in der Regel aus. Für alles, was mit E-Mail-Protokollen, SFTP, MQTT oder WebSocket zu tun hat, ist curl das einzige der beiden Programme, das in Frage kommt.
Neuere HTTP-Versionen
curl unterstützt HTTP 0.9, 1.0, 1.1, 2 und 3. Wenn Sie speziell testen müssen, wie sich ein Server über HTTP/2 oder HTTP/3 verhält, ist das eine Aufgabe für curl.
Weitere Proxy-Typen
curl unterstützt HTTPS-Proxys sowie SOCKS4- und SOCKS5-Proxys. Dies gehört zu den Funktionen, über die curl verfügt, wget jedoch nicht, und das hat konkrete Auswirkungen – siehe den Abschnitt über Proxys weiter unten.
Parallele Übertragungen
curl kann mit „-Z“ mehrere Übertragungen gleichzeitig ausführen. Dies ist nützlich, wenn viele kleine Ressourcen abgerufen werden, bei denen die Latenzzeit beim nacheinander Ausführen der einzelnen Vorgänge eine große Rolle spielt.
Bidirektionale Übertragung und Formular-Uploads
Daten senden, nicht nur empfangen. Multipart-Formular-Uploads, PUT, beliebige Methoden. wget ist im Grunde ein Tool zum Abrufen von Daten; curl ist ein Übertragungs-Tool, und Uploads sind ein zentraler Anwendungsfall.
Es ist bereits auf mehr Rechnern installiert
curl ist auf macOS sowie unter Windows 10 und 11 vorinstalliert. Auf einem Windows-Rechner ohne zusätzliche Installation ist curl verfügbar, wget hingegen in der Regel nicht – was für plattformübergreifende Skripte eine größere Rolle spielt, als es eigentlich sollte.
Was wget kann, was curl nicht kann
Auch vom curl-Entwickler selbst – was diese Liste besonders glaubwürdig macht.
Rekursives Herunterladen
„Die größte Stärke von wget im Vergleich zu curl ist seine Fähigkeit, rekursiv herunterzuladen.“
Das ist der entscheidende Punkt, und es handelt sich dabei nicht um eine unbedeutende Funktion. wget kann Links auf einer Seite folgen und die gefundenen Inhalte bis zu einer bestimmten Tiefe herunterladen, wobei es die Links dabei für die lokale Anzeige umwandelt. Das Spiegeln einer Dokumentationsseite zum Offline-Lesen erfolgt mit einem einzigen Befehl.
wget -r -np -k -p https://example.com/docs/
Rekursiv, ohne übergeordnete Verzeichnisse, Konvertierung von Links für die lokale Anzeige, Abruf von Seitenkomponenten wie Bildern und Stylesheets.
curl kann das überhaupt nicht. curl ruft die URLs ab, die man ihm angibt. Es analysiert kein HTML, entdeckt keine Links und hat kein Konzept einer Website. Wenn Ihre Aufgabe lautet „Kopiere diesen Abschnitt einer Website“, ist wget die Lösung, und es gibt kein curl-Äquivalent, das einen Versuch wert wäre.
Unterbrochene Übertragungen fortsetzen
wget „kann eine vorzeitig abgebrochene Übertragung wiederherstellen und den Download fortsetzen“. Mit -c wird ein unterbrochener Download an der Stelle fortgesetzt, an der er aufgehört hat.
curl kann dies ebenfalls mit „-C -“ bewerkstelligen, doch das Verhalten von wget hinsichtlich Wiederholungsversuchen und Wiederaufnahme ist automatischer und fehlertoleranter – was wichtig ist, wenn es sich um große Datenmengen handelt und die Verbindung unzuverlässig ist.
Für den offensichtlichen Fall sind keine Optionen erforderlich
wget lädt eine Datei ohne Optionen herunter. curl „benötigt -o oder -O“, um in eine Datei statt in das Terminal zu schreiben.
Für die mit Abstand häufigste Aufgabe, die jeder mit einem der beiden Tools ausführt – das Herunterladen dieser Datei –, ist wget der kürzere Befehl, und diese Kürze ist ein echter Vorteil bei einem Tool, das man täglich nutzt.
Sinnvollere Standardeinstellungen für das Herunterladen
wget „aktiviert standardmäßig mehr Funktionen: Cookies, Verfolgungen von Weiterleitungen, Zeitstempel“.
Besonders erwähnenswert ist die Zeitstempelung: Mit der Option „-N“ lädt wget eine Datei nur dann erneut herunter, wenn die Version auf dem Remote-Server neuer ist. Für die geplante Synchronisierung einer Reihe von Dateien ist dies genau das richtige Verhalten, und curl bietet hierfür keine direkte Entsprechung.
Lizenz
wget unterliegt der GPL v3; curl der MIT-Lizenz. Wenn Sie eines der beiden Programme in ein Produkt einbinden, ist dieser Unterschied wahrscheinlich wichtiger als jede auf dieser Seite beschriebene Funktion.
Standardeinstellungen, die Sie Zeit kosten
Die Unterschiede, die am ehesten zu einem verwirrenden Nachmittag führen.
Weiterleitungen
wget folgt standardmäßig Weiterleitungen. curl tut dies nicht.
Dies ist der häufigste Grund für die Frage „Warum hat curl nichts zurückgegeben?“. Der Server antwortete mit einem 301-Code, curl meldete dies und stoppte den Vorgang, und die Standardausgabe erscheint leer.
curl -L https://example.com/moved # follow them
wget https://example.com/moved # already following them
Das ist kein Versäumnis von curl. Einer Umleitung zu folgen bedeutet, eine Anfrage zu stellen, die man nicht gestellt hat, an einen Host, den man nicht angegeben hat, und das Prinzip von curl ist es, das zu tun, was ihm gesagt wurde, und den Rest zu melden. Das Prinzip von wget ist es, die Datei zu holen, und die Datei wurde verschoben.
Ausgabeziel
Wurde oben bereits behandelt, ist aber eine Wiederholung wert, da viele Nutzer immer wieder darauf hereinfallen. „curl URL“ gibt die Ausgabe an; „wget URL“ speichert sie.
Fehlerbehandlung
Beide Programme haben eine Eigenart. „curl“ behandelt einen 404-Fehler als erfolgreiche Übertragung und beendet sich mit dem Status 0 – die Übertragung hat funktioniert, der Server hat geantwortet. Verwende „-f“, damit HTTP-Fehler einen Exit-Status ungleich Null erzeugen.
wget beendet sich bei HTTP-Fehlern standardmäßig mit einem Status ungleich Null, was für einen Downloader das intuitivere Verhalten ist.
In Skripten: „curl -sSf“ ist die Kombination, die man sich merken sollte, und ihr Fehlen ist ein häufiger Grund dafür, dass ein fehlgeschlagener Auftrag scheinbar funktioniert.
Wiederholungsversuche
wget versucht es standardmäßig erneut. curl tut dies nur, wenn Sie es mit „--retry“ anweisen.
Auch dies steht im Einklang mit den Modellen: Ein Downloader sollte beharrlich bleiben, ein Übertragungstool sollte Fehler melden.
Der praktische Rat
Wenn Sie automatisierte Skripte schreiben, legen Sie das Verhalten explizit fest, anstatt sich auf die Standardeinstellungen der jeweiligen Tools zu verlassen. curl -sSfL --max-time 30 beschreibt, was Sie wollen. Ebenso wget --tries=3 --timeout=30. Explizite Befehle sind auch dann noch verständlich, wenn sie in einem Jahr von jemand anderem gelesen werden.
Im Vergleich
| Aufgabe | curl | wget |
|---|
| Im Terminal anzeigen | curl URL | wget -O - URL |
| In Datei speichern | curl -O URL | wget URL |
| Unter gewähltem Namen speichern | curl -o name URL | wget -O name URL |
| Weiterleitungen folgen | curl -L URL | Standard |
| Download fortsetzen | curl -C - -O URL | wget -c URL |
| Nur Header | curl -I URL | wget --spider -S URL |
| Benutzerdefinierter Header | curl -H "K: V" URL | wget --header="K: V" URL |
| Basic-Authentifizierung | curl -u user:pass URL | wget --user=u --password=p URL |
| POST-Daten | curl -d "a=b" URL | wget --post-data="a=b" URL |
| Quiet-Modus | curl -s URL | wget -q URL |
| Website spiegeln | nicht möglich | wget -m URL |
| Eine Datei hochladen | curl -T file URL | nicht möglich |
| „SOCKS5“ verwenden | curl -x socks5h://host URL | nicht nativ |
| Parallele Übertragungen | curl -Z ... | nicht unterstützt |
Die Tabelle lesen
Die Symmetrie gilt für die alltäglichen Vorgänge – die meisten Aufgaben haben ein direktes Äquivalent, wobei unterschiedliche Schreibweisen der Flags eher lästig als wichtig sind.
Die vier als „nicht möglich“ gekennzeichneten Zeilen sind diejenigen, bei denen die Entscheidung tatsächlich getroffen wird. Das Spiegeln einer Website ist nur mit wget möglich. Das Hochladen ist nur mit curl möglich. SOCKS-Proxying ist nur mit curl möglich. Parallele Übertragungen sind nur mit curl möglich.
Wenn Ihre Aufgabe in einer dieser Zeilen steht, ist der Vergleich beendet und Sie können aufhören zu lesen. Ist dies nicht der Fall, funktioniert jedes der beiden Tools, und Sie sollten dasjenige verwenden, mit dem Sie flüssiger umgehen können.
Ein Hinweis zur Flag-Kollision
„-O“ hat in den beiden Tools unterschiedliche Bedeutungen, was eine echte Falle darstellt.
In curl bedeutet -O „unter dem Dateinamen aus der URL speichern“ und -o name bedeutet „unter diesem Namen speichern“. In wget bedeutet -O name „unter diesem Namen speichern“ und die andere Option ist nicht erforderlich.
Daher sind curl -O und wget -O nicht gleichbedeutend, und ein unachtsam zwischen den beiden Tools übersetzter Befehl führt zu unerwarteten Ergebnissen.
Je nach Aufgabe: Was ist zu verwenden?
Eher eine Entscheidungshilfe als eine pauschale Empfehlung.
Verwenden Sie wget, wenn
Sie eine Datei auf der Festplatte haben möchten. Keine Optionen, kein Fortschrittsbalken, sinnvolle Standardeinstellungen. Dies ist für die meisten Nutzer der häufigste Anwendungsfall.
Sie möchten einen Spiegel erstellen oder rekursiv herunterladen. Die einzige Option. wget -m oder wget -r mit entsprechenden Begrenzungen.
Die Verbindung ist unzuverlässig und die Datei ist groß. Automatische Wiederholungsversuche und Wiederaufnahme unter -c.
Sie halten eine lokale Kopie synchron. -N mit Zeitstempel lädt nur die geänderten Teile herunter.
Sie möchten den kürzestmöglichen Befehl für einen unkomplizierten Download in einem Skript, das jemand anderes lesen wird.
Verwenden Sie curl, wenn
Sie mit einer API arbeiten. Header, Methoden, Request-Inhalte und Ausgabe, die an einen JSON-Prozessor weitergeleitet wird.
Sie müssen Daten senden, nicht nur abrufen.
Sie führen eine Fehlersuche durch. -v und -w zeigen Ihnen die gesendete Anfrage, die Antwort und die nach Phasen aufgeschlüsselten Zeiten an. Dies ist der mit Abstand größte Vorteil von curl im Alltag.
Sie benötigen ein Protokoll, das über HTTP und FTP hinausgeht.
Sie benötigen Unterstützung für SOCKS- oder HTTPS-Proxys.
Sie arbeiten unter Windows oder macOS, ohne dass etwas installiert ist, wo curl vorhanden ist, wget jedoch in der Regel nicht.
Sie schreiben etwas, das zu Code werden wird, da sich die Form des Befehls dank der Bindungen von libcurl ganz natürlich umsetzen lässt.
Beide verwenden
Die ehrliche Antwort für die meisten Arbeitsumgebungen. Sie sind klein, sie sind kostenlos und sie sind jeweils in unterschiedlichen Bereichen gut. Beide installiert zu haben und je nach Bedarf das passende zu wählen, ist keine Unentschlossenheit – es ist das richtige Ergebnis davon, dass es sich um wirklich unterschiedliche Werkzeuge handelt.
Proxys in beiden Fällen
Unser Bereich, und es gibt einen wesentlichen Unterschied, den man kennen sollte.
curl
# HTTP proxy
curl -x http://proxy.example.com:8080 https://example.com
# With credentials
curl -x http://user:pass@proxy.example.com:8080 https://example.com
# SOCKS5, with the proxy resolving hostnames
curl -x socks5h://proxy.example.com:1080 https://example.com
curl unterstützt HTTP-Proxys, HTTPS-Proxys sowie SOCKS4/SOCKS5
– alles über dieselbe Option „-x
“ mit einem Schema.
wget
# Via environment variables
export http_proxy="http://proxy.example.com:8080"
export https_proxy="http://proxy.example.com:8080"
wget https://example.com
# With credentials
wget --proxy-user=user --proxy-password=pass https://example.com
wget liest die Standard-Proxy-Umgebungsvariablen aus und verfügt über Optionen für Proxy-Anmeldedaten.
Der entscheidende Unterschied
wget bietet keine native SOCKS-Unterstützung. Im Vergleich von curl werden SOCKS4 und SOCKS5
als Funktionen aufgeführt, die curl unterstützt, wget jedoch nicht.
Wenn Ihr Proxy ausschließlich SOCKS unterstützt, kann wget ihn nicht direkt nutzen. Die üblichen Workarounds bestehen darin, wget über ein Tool wie proxychains auszuführen oder eine lokale HTTP-zu-SOCKS-Brücke davor zu schalten – beides funktioniert, fügt jedoch eine Komponente hinzu, die unbemerkt ausfallen kann.
Wenn Sie sich zwischen den beiden entscheiden müssen und SOCKS in Ihrer Konfiguration vorhanden ist, ist die Entscheidung damit gefallen.
Noch einmal zum Thema DNS
Es lohnt sich, dies zu wiederholen, da es immer dann gilt, wenn curl mit SOCKS verwendet wird. socks5://
löst Hostnamen auf Ihrem Rechner auf; socks5h://
sendet den Hostnamen an den Proxy. Im ersten Fall wird jeder von Ihnen besuchte Host an Ihren lokalen Resolver weitergegeben, auch wenn der Datenverkehr korrekt weitergeleitet wird, und es kann vorkommen, dass Sie für Websites mit standortabhängiger Infrastruktur eine regional falsche Adresse erhalten.
Verwenden Sie socks5h://
, es sei denn, Sie haben einen konkreten Grund, dies nicht zu tun.
Und der Teil, in dem wir uns selbst von einem Verkauf abbringen
Wenn Sie eine Datei herunterladen, eine API aufrufen, für die Sie Zugangsdaten haben, oder prüfen, ob ein Dienst verfügbar ist, benötigen Sie überhaupt keinen Proxy. Proxys verdienen ihren Platz in diesen Tools für die geografische Überprüfung und für Volumenaufgaben, die durch Ratenbegrenzungen pro Adresse begrenzt sind. Bei allem anderen verursachen sie Latenz, einen Ausfallpunkt und Kosten.
Wenn keines der beiden Tools das richtige ist
In einigen häufigen Situationen ist etwas anderes erforderlich, und der Einsatz eines der beiden Tools kostet einen ganzen Nachmittag.
Die Seite wird per JavaScript gerendert. Beide Tools rufen die vom Server gesendeten Daten ab. Wenn der Inhalt anschließend im Browser zusammengestellt wird, erhält man eine leere Hülle, und kein Flag kann das beheben. Sie benötigen einen headless Browser – Playwright, Puppeteer oder ähnliches.
Sie müssen mit der Seite interagieren. Klicken, scrollen, Formulare ausfüllen, darauf warten, dass etwas erscheint. Gleiche Antwort.
Sie entwickeln etwas, das im Code wartbar ist. Der Aufruf von curl aus einer Anwendung heraus ist eine gängige Abkürzung, die sich jedoch nicht bewährt. Verwende die HTTP-Bibliothek deiner Sprache oder die Bindungen von libcurl und sorge für eine ordnungsgemäße Fehlerbehandlung.
Du musst ein Verzeichnis in beide Richtungen synchronisieren. rsync ist das richtige Tool dafür und leistet dabei deutlich bessere Arbeit als ein rekursives wget.
Sie übertragen Daten zwischen Servern, die Sie kontrollieren. scp, rsync oder sftp – speziell dafür entwickelt, schneller und sie handhaben Berechtigungen und Teilübertragungen korrekt.
Sie müssen den Datenverkehr während der Übertragung überprüfen oder ändern. Ein Intercepting-Proxy-Tool ist das richtige Mittel.
Sie laden Medien von einer Videoplattform herunter. Speziell entwickelte Tools übernehmen das Parsen des Manifests und das Zusammenstellen des Streams – was keines der beiden oben genannten Tools leistet.
Die Daten werden auf andere Weise bereitgestellt. Eine API, ein Massen-Download, ein öffentlicher Datensatz, ein RSS-Feed. Die Überprüfung dauert zehn Minuten und beendet das Projekt häufig, bevor es überhaupt begonnen hat.
Die Warnung zum rekursiven Download
Eine spezielle Warnung bezüglich „wget -r“, das zwar leistungsstark ist, aber leicht auf etwas zielen kann, das Sie gar nicht beabsichtigt haben.
Ohne „-np“ kann es in übergeordnete Verzeichnisse vordringen. Ohne „--level“ kann es sehr tief in die Unterverzeichnisse vordringen. Ohne --wait werden Anfragen so schnell gestellt, wie der Server antwortet – was gegenüber der Infrastruktur anderer sehr unhöflich ist und leicht zu einer Sperrung führen kann.
Mindestens: wget -r -np --level=3 --wait=1 URL. Und überprüfen Sie zunächst robots.txt sowie die Nutzungsbedingungen der Website – wget respektiert standardmäßig robots.txt, und die Deaktivierung dieser Option ist eher eine bewusste Entscheidung als eine Annehmlichkeit.
Häufig gestellte Fragen
Was ist der Unterschied zwischen curl und wget?
curl funktioniert wie cat – es ruft Daten ab und schreibt sie in die Standardausgabe. wget funktioniert wie cp – es ruft Daten ab und speichert eine Datei. curl unterstützt weitaus mehr Protokolle, Uploads, SOCKS-Proxys und parallele Übertragungen; wget kann rekursiv herunterladen und Websites spiegeln, was curl überhaupt nicht kann.
Ist curl besser als wget?
Keines von beiden ist besser. curl ist ein Übertragungstool mit einer zugrunde liegenden Bibliothek und einer weitaus größeren Protokollauswahl; wget ist ein Downloader mit besseren Standardeinstellungen für das Herunterladen und einer einzigartigen rekursiven Fähigkeit. Die meisten Nutzer profitieren davon, beide zu haben.
Kann curl rekursiv herunterladen wie wget?
Nein. curl ruft die angegebenen URLs ab und analysiert weder HTML noch entdeckt es Links. Rekursives Herunterladen und das Spiegeln von Websites sind ausschließlich mit wget möglich, und der Betreuer von curl selbst bezeichnet dies als die größte Stärke von wget.
Warum folgt curl keinen Weiterleitungen?
Das ist beabsichtigt. curl gibt lediglich die Antwort des Servers wieder, anstatt Anfragen zu stellen, die Sie nicht gestellt haben. Fügen Sie „-L“ hinzu, um Weiterleitungen zu verfolgen. wget folgt standardmäßig, da sein Ziel das Abrufen der Datei ist und die Datei verschoben wurde.
Was ist schneller, curl oder wget?
Bei einer einzelnen Übertragung ist der Unterschied vernachlässigbar – beide sind durch das Netzwerk begrenzt. curl kann mit „-Z“ mehrere Übertragungen parallel ausführen, was es beim Abrufen vieler kleiner Ressourcen deutlich schneller macht.
Unterstützt wget SOCKS-Proxys?
Nicht nativ. curl unterstützt SOCKS4-, SOCKS5- und HTTPS-Proxys; wget nutzt die standardmäßigen HTTP-Proxy-Umgebungsvariablen. Für SOCKS mit wget benötigen Sie einen Wrapper wie proxychains oder eine lokale Bridge.
Was sollte ich in einem Skript verwenden?
Beides, mit expliziten Optionen. Für APIs und alles, bei dem Sie die Antwort überprüfen, curl -sSfL --max-time 30. Zum Abrufen von Dateien wget --tries=3 --timeout=30. Verlassen Sie sich bei der Automatisierung nicht auf die Standardeinstellungen der beiden Tools.
Ist curl oder wget standardmäßig installiert?
curl ist unter macOS sowie Windows 10 und 11 vorinstalliert. wget gehört bei den meisten Linux-Distributionen zum Standard, fehlt jedoch häufig unter macOS und Windows. Bei plattformübergreifenden Skripten ist es sicherer, von curl auszugehen.
Fazit
Der Vergleich lässt sich schneller klären, als es die Beliebtheit der beiden Tools vermuten lässt, da sie auf unterschiedlichen Verben basieren.
curl überträgt. wget lädt herunter. curl schreibt wie bei cat in die Standardausgabe, führt genau das aus, was von ihm verlangt wurde, und meldet den Rest – weshalb es Umleitungen nicht folgt, keine Wiederholungsversuche unternimmt und ein Flag benötigt, um eine Datei zu schreiben. wget schreibt wie bei cp auf die Festplatte, und alles, was es standardmäßig tut, ergibt sich aus dem Ziel, am Ende eine existierende Datei zu erhalten.
Vier Funktionen entscheiden die Wahl endgültig, und wenn Ihre Aufgabe eine davon beinhaltet, ist der Rest des Vergleichs irrelevant. Rekursives Herunterladen und das Spiegeln von Websites sind ausschließlich mit wget möglich – der Betreuer von curl selbst bezeichnet dies als die größte Stärke von wget, und curl verfügt über keine entsprechende Funktion. Uploads, SOCKS-Proxys und parallele Übertragungen sind ausschließlich mit curl möglich.
Abgesehen davon funktionieren beide, und die praktischen Unterschiede bestehen in der Schreibweise der Optionen und den Standardeinstellungen. Achten Sie bei der Übersetzung von Befehlen zwischen den beiden auf die Kollision „-O“, da dieser Befehl in jedem der Programme das Gegenteil bedeutet. Und bei allen automatisierten Vorgängen sollten Sie Ihre Absichten explizit angeben, anstatt sich auf die Annahmen eines der beiden Tools zu verlassen – „curl -sSfL --max-time 30“ und „wget --tries=3 --timeout=30“ sind beides Befehle, die auch für denjenigen, der sie nächstes Jahr liest, noch Sinn ergeben werden.
Zum Thema Proxys: Wir verkaufen sie, doch für die meisten Anwendungsfälle dieser Tools sind sie nicht erforderlich. Wenn du doch einen benötigst, bietet „curl“ eine umfassendere Unterstützung, und wichtiger als das Tool selbst ist, dass du socks5h:// statt socks5:// verwendest, damit deine Hostnamen-Abfragen denselben Weg nehmen wie dein Datenverkehr.
Die ehrliche Empfehlung lautet, beide zu installieren. Sie sind klein, sie sind kostenlos, und die Debatte darüber, welches besser ist, ist seit Jahren dadurch entschieden, dass die meisten Arbeitsrechner beide haben.
