Diagrama de Venn de curl-wget

• wget no debe verse como un competidor directo de curl, sino como una herramienta con funciones parcialmente superpuestas que puede usarse junto con curl según la tarea
• El criterio de elección no es la preferencia por una herramienta, sino cuál se ajusta mejor para terminar la tarea; si wget es más adecuado, conviene usar wget
• Las diferencias técnicas y las áreas de superposición entre curl y wget se resumieron en un diagrama de Venn para verlas de un vistazo, y también se ofrece la imagen en resolución completa
• Los dos proyectos no están enfrentados; desde el lado de curl se ha contribuido código a wget, y varios mantenedores de wget también han contribuido a curl
• Los errores u omisiones del diagrama pueden actualizarse, y se puede consultar más detalle en un documento comparativo aparte y en una tabla de comparación de herramientas de descarga

---

Criterios para ver curl y wget

• wget es más bien una herramienta complementaria que una competidora de curl
• Aunque ambas herramientas tienen algunas funciones superpuestas, lo importante no es insistir en una herramienta específica, sino elegir según la tarea que se quiere resolver
• Si en alguna situación wget resulta más adecuado para terminar la tarea, es mejor usar wget

Diferencias resumidas en un diagrama de Venn

• Se creó un diagrama de Venn para mostrar visualmente las diferencias técnicas y algunas similitudes entre curl y wget
• Al hacer clic en la imagen del diagrama, se puede ver la versión en resolución completa
• Se pide avisar si se detectan problemas o elementos faltantes, y el diagrama puede actualizarse si hace falta

Colaboración entre proyectos

• Desde el lado de curl se ha contribuido código a wget
• Varios mantenedores de wget también han contribuido a curl
• La relación entre ambos proyectos se parece más a la colaboración que a la competencia o el enfrentamiento

Otros materiales comparativos para consultar

• curl vs wget: documento comparativo entre curl y wget
• Compare curl with other download tools: tabla comparativa de curl y otras herramientas de descarga
• OpenHub’s curl vs wget table: tabla comparativa curl-vs-wget de OpenHub

[GN⁺]

Opiniones en Hacker News

• Creo que del lado de Wget habría que incluir al menos valores predeterminados razonables, reanudación de descargas y reintentos ante errores.
  Hace poco tuve que escribir un script para descargar un archivo muy grande con una conexión inestable, y la idea común entre los ingenieros era que para ese trabajo había que usar Wget.
  También probé curl, pero por defecto no reanudaba ni reintentaba, y tuve que leer el manual para especificar varias opciones y argumentos. Siento que ese comportamiento debería venir activado por defecto.
  Con Wget bastó una sola opción, --continue, para activar la reanudación en todas las situaciones, incluso después de un fallo; y la introducción del manual dice que está diseñado para funcionar de forma robusta en redes lentas o inestables, y que si una descarga falla seguirá reintentando hasta recibir el archivo completo.
  Con curl seguramente se pueden ajustar todas las opciones para que funcione de forma confiable con una mala conexión, pero Wget parece traer ese comportamiento básico ya activado, lo que me hace confiar en que actuará como espero incluso en situaciones de error que no pude probar directamente. Aunque se actualice el protocolo HTTP, es probable que un Wget nuevo lo soporte por defecto, mientras que curl podría necesitar un switch nuevo para activar el comportamiento mejorado, y después de lanzar un producto ya no se puede agregar.
  Para mí, curl es una herramienta de bajo nivel excelente y muy versátil, y su CLI refleja esa naturaleza; pero en tareas cotidianas prefiero Wget porque funciona mucho mejor de entrada. Su manual también se puede ojear más rápido, probablemente porque no soporta todos esos protocolos oscuros mencionados aquí.

  • Estoy de acuerdo con lo de valores predeterminados razonables.
    Solo el hecho de que wget url descargue y guarde la URL hace que Wget gane para uso en línea de comandos, en mi opinión.
  • curl tiene exactamente esa funcionalidad. La reanudación es con el flag -C, y los reintentos con --retry.
    Personalmente, los valores predeterminados de curl también me parecen bastante razonables, y en una herramienta como curl no querría que ninguna de esas dos cosas estuviera activada por defecto.
  • También habría que agregar -i, que permite que Wget lea URLs desde un archivo.
    En particular, wget -i - lee desde la entrada estándar, así que es muy útil en pipelines.
    Hasta donde sé, curl no puede hacer eso. Normalmente te dicen que uses xargs, pero eso espera a que lleguen todas las URLs antes de ejecutar curl, así que pierdes el paralelismo entre el comando que genera las URLs y el comando que las descarga; como sustituto, queda medio flojo.
  • Ambas herramientas tienen sus propios usos. Con la aparición de modelos de lenguaje grandes como ChatGPT, creo que se volvió mucho más fácil obtener el conjuro correcto de línea de comandos, uses la herramienta que uses.
    Aunque hayas leído el manual antes, no es fácil recordar exactamente el flag que quieres, y normalmente da menos trabajo validar una línea de comandos generada que armarla desde cero leyendo el manual.
    En la web moderna, a veces es más fácil usar herramientas como Puppeteer en scripts propios, sobre todo si el sitio con el que interactúas usa mucho JavaScript.
  • Otra cosa que personalmente me molesta es que el parser de URLs de curl es mucho más estricto que el de wget.
    Por ejemplo, $ curl -sSLOJ 'example.com/file name.txt' da el error curl: (3) URL using bad/illegal format or missing URL, y $ curl -sSLOJ 'example.com/file%20name.txt' crea un archivo llamado file%20name.txt.
    En cambio, wget crea un archivo llamado "file name.txt" con ambas URLs, sin flags adicionales. Eso sí, como esta URL de ejemplo devuelve 404, estrictamente habría que agregar también --content-on-error a wget.

• Para mucha gente, la diferencia clave probablemente sea entre una herramienta que escribe por defecto en la salida estándar y una herramienta que crea archivos por defecto.

  • O una herramienta que por defecto puedes pipear a sh ;-)

• Para mí, la característica decisiva de Wget es que, por defecto, descarga el archivo con un nombre de archivo derivado de la URL.
  Si ejecutas wget url://to/file.htm, en el directorio de trabajo actual aparece un archivo llamado "file.htm".
  Con curl tienes que escribir algo como curl url://to/file.htm > file.htm, u otro conjuro menos cómodo.

  • curl -O
    https://curl.se/docs/manpage.html#-O
  • Sí, pero hay casos como wget "url://to/file.htm?uid=foo&q=bar&rnd=4".
  • Siempre he visto eso como una función equivocada de Wget, por el principio general de que una utilidad de línea de comandos, salvo indicación explícita, debería escribir su resultado principal en la salida estándar.
  • curl -O es más cómodo.
    Si comparamos esa “característica decisiva” con cat, sería como si cat file.html pasara a ser cat file.html > file.html. Entonces, cuando de verdad quisieras imprimir y no copiar, tendrías que escribir algo como cat file.html -o -, así que me alegra que curl no tenga esa función.

• Daniel Stenberg pertenece a esa rara clase de desarrolladores que ponen corazón y alma en sus creaciones.
  En la big tech moderna, los desarrolladores parecen sombras, engranes reemplazables de una máquina de hacer dinero, y esa cualidad parece estar desapareciendo cada vez más.
  Él parece tratar a curl como la huella que deja en el mundo de la tecnología.

  • El software libre está lleno de gente así. Por eso uso software libre aunque sea técnicamente inferior.
    Claro que hoy en día muchas veces en realidad es técnicamente mejor, así que la elección se vuelve más fácil.
  • Cuando trabajas para una empresa quizá no pongas el corazón en tus creaciones, pero si tienes un proyecto personal popular que te genera mucho efectivo, creo que cualquiera le dedicaría ese nivel de entrega.

• Esta comparación parece un poco vieja. Por ejemplo, en el diagrama faltan estas dos cosas del lado de Wget:
  HTTP PUT es posible con wget --method=PUT --body-data=, y los proxies con HTTPS también, con algo como wget --use-proxy=on --https_proxy=[https://example.com](<https://example.com>;).
  curl tiene de forma consistente más opciones y flexibilidad, pero varias de las cosas del lado derecho del diagrama de Venn también son posibles en cierta medida con Wget.

  • Según la página del manual, también parece tener soporte para FTP.

• Vaya, no sabía que curl soportaba tantos protocolos. Aun así, la pequeña zona de intersección probablemente sea la parte que realmente usa más del 90% de los usuarios de curl/Wget.
  Desde la perspectiva de un desarrollador, el área que se superpone no es tan grande, pero desde la perspectiva de un usuario puede verse mucho más grande.

• La parte que más me gustó del texto fue esta frase:
  “He contribuido código a wget. Varios mantenedores de wget también han contribuido a curl. Todos somos amigos.”

• La comparación hecha por Daniel Stenberg también es lectura obligada:
  https://daniel.haxx.se/docs/curl-vs-wget.html

  • Esta nueva comparación también es de Daniel Stenberg y está alojada en el mismo dominio, pero está en su blog, no en la documentación de curl.

• Antes usaba Wget cuando quería duplicar un sitio web. Wget es una herramienta especializada.
  curl es una biblioteca de solicitudes de propósito general con un frontend CLI, y también se integra en otros programas o se usa como API de biblioteca estándar en PHP y otros entornos.

  • Personalmente, para hacer mirrors me gusta httrack, pero Wget tiene conversión de href/src, así que a veces encaja mejor para ciertos objetivos.

• Creo que el uso más común está en la parte que se superpone entre ambos. Por eso me gustaría ver un diagrama de Venn que muestre en qué sistemas operativos e imágenes Docker viene instalada por defecto cada herramienta.