--libcurl

Artículo original ↗ Discusión en Hacker News ↗

La opción de larga data `--libcurl` de Curl, que genera código C equivalente para cualquier comando curl, está recibiendo atención renovada como un puente potente desde llamadas HTTP en línea de comandos hacia el uso embebido de la biblioteca. Los comentaristas destacan cómo esto facilita aprender la API de libcurl, permite flujos de trabajo de “grabar y personalizar” similares a las macros de Office y a “copy as cURL” del navegador, y convierte efectivamente a curl en una representación intermedia que las herramientas pueden traducir a muchos lenguajes. Otros contrastan estos generadores de código deterministas con soluciones basadas en LLM, debaten ideas más amplias sobre sistemas y shells más interactivos y reflectivos, y señalan herramientas relacionadas como curlconverter y Hurl que se apoyan en la ubicuidad de curl.

Qué hace --libcurl y por qué gusta

  • Genera código C compilable usando libcurl que refleja un comando curl dado.
  • Se ve como:
    • Un generador de boilerplate para que no tengas que aprender cada opción de libcurl.
    • Documentación “en vivo” de la biblioteca: ejecutas un comando y ves exactamente qué llamadas a la API hay que hacer.
    • Un camino suave desde el uso en CLI hasta incrustar libcurl en aplicaciones.
  • Flujos de trabajo de ejemplo: curl … --libcurl file.c y luego compilar con -lcurl, o mediante make.

Patrón: “Grabar acciones, mostrar el código”

  • Comparado con macros de Office VBA y otras herramientas que te permiten realizar acciones y luego inspeccionar el código generado.
  • Se mencionan ideas similares:
    • La herramienta de exploración de código del Open XML SDK para la documentación de Office.
    • ASMifier de ASM, que produce código Java que manipula bytecode.
  • Deseo de ver este patrón en herramientas gráficas del sistema (ajustes de Gnome, configuración de firewall/red) que podrían emitir comandos equivalentes de CLI/script.

cURL como representación intermedia

  • Las devtools del navegador “Copy as cURL” se usan muchísimo, y luego se convierten a:
    • Python (p. ej. requests), JavaScript, Go, R (httr2), colecciones de Postman, etc.
  • cURL es, de hecho, una “IR” común para solicitudes HTTP:
    • Formato de exportación e importación ampliamente compatible entre herramientas.
    • Más conciso que HTTP en bruto; oculta cabeceras poco interesantes y valores por defecto.
  • Algunos señalan que “Copy as cURL” a menudo incluye cabeceras innecesarias.
  • Un comentarista argumenta que HTTP puede hacer cosas que cURL no puede (por ejemplo, pipeline en HTTP/1.1).

LLMs frente a generadores de código deterministas

  • Afirmaciones en tono de broma de que las LLM hacen obsoleto --libcurl.
  • Contrapunto fuerte: los generadores deterministas como --libcurl y otras herramientas de codegen son:
    • Predecibles, probados en batalla, offline y de bajo consumo de recursos.
    • Libres de preocupaciones sobre recolección de datos y ética del entrenamiento.
  • Algunos aún combinan esto con LLMs (por ejemplo, usando IA para convertir el C generado a Python).

Críticas, limitaciones y seguridad

  • Informes de que algunos flags (p. ej. --upload-file) no se traducen bien.
  • Preocupaciones sobre “demasiados flags” y el aumento de complejidad; sugerencia de un binario separado curl-as-libcurl.
  • Temor a “más C inseguro en internet”, contrarrestado por:
    • Confianza en la madurez de libcurl.
    • Observación de que el código generado es simple; el verdadero riesgo está en la lógica añadida por el usuario.

Herramientas relacionadas y ecosistema

  • Menciones de:
    • Hurl: una herramienta CLI de pruebas construida sobre libcurl con encadenamiento y aserciones.
    • Múltiples convertidores de curl→código (web y CLI) y sus implicaciones de privacidad.
    • Reflexiones sobre que necesitar codegen en absoluto pone de relieve la verbosidad de C frente a lenguajes como Python/Node.