--libcurl

Artigo original ↗ Discussão no Hacker News ↗

A opção de longa data do Curl `--libcurl`, que gera código C equivalente para qualquer comando curl, está recebendo atenção renovada como uma ponte poderosa entre chamadas HTTP na linha de comando e o uso embutido da biblioteca. Comentadores destacam como isso torna a API do libcurl mais fácil de aprender, possibilita fluxos de trabalho de “registrar e personalizar” semelhantes a macros do Office e ao “copy as cURL” do navegador, e efetivamente transforma o curl em uma representação intermediária que ferramentas podem traduzir para muitas linguagens. Outros contrapõem esses geradores determinísticos a soluções baseadas em LLMs, debatem ideias mais amplas sobre sistemas e shells mais interativos e reflexivos, e apontam ferramentas relacionadas como curlconverter e Hurl, que se apoiam na ubiquidade do curl.

O que --libcurl faz e por que as pessoas gostam

  • Gera código C compilável usando libcurl que espelha um comando curl dado.
  • Visto como:
    • Gerador de boilerplate, para você não precisar aprender todas as opções de libcurl.
    • Documentação “viva” da biblioteca: execute um comando e veja exatamente quais chamadas de API fazer.
    • Um caminho suave do uso na CLI para incorporar libcurl em aplicações.
  • Fluxos de trabalho de exemplo: curl … --libcurl file.c depois compile com -lcurl, ou via make.

Padrão: “Registrar ações, mostrar o código”

  • Comparado a macros do Office VBA e outras ferramentas que permitem executar ações e depois inspecionar o código gerado.
  • Ideias semelhantes mencionadas:
    • Ferramenta de navegação de código do Open XML SDK para documentos do Office.
    • ASMifier do ASM produzindo código Java que manipula bytecode.
  • Desejo de ver esse padrão em ferramentas GUI de sistema (configurações do Gnome, configuração de firewall/rede) que poderiam gerar comandos equivalentes de CLI/script.

cURL como uma Representação Intermediária

  • O “Copy as cURL” das devtools do navegador é muito usado e depois convertido para:
    • Python (por exemplo, requests), JavaScript, Go, R (httr2), coleções do Postman, etc.
  • cURL é efetivamente uma “IR” comum para requisições HTTP:
    • Formato de exportação e importação amplamente suportado entre ferramentas.
    • Mais conciso do que HTTP bruto; oculta cabeçalhos e padrões pouco interessantes.
  • Alguns observam que “Copy as cURL” frequentemente inclui cabeçalhos desnecessários.
  • Um comentarista argumenta que HTTP pode fazer coisas que o cURL não pode (por exemplo, pipeline no HTTP/1.1).

LLMs vs geradores determinísticos de código

  • Afirmações bem-humoradas de que LLMs tornam --libcurl obsoleto.
  • Contra-argumento forte: geradores determinísticos como --libcurl e outras ferramentas de codegen são:
    • Previsíveis, testados em batalha, offline e com baixo uso de recursos.
    • Livres de preocupações com coleta de dados e ética de treinamento.
  • Alguns ainda combinam isso com LLMs (por exemplo, usando IA para converter o C gerado em Python).

Críticas, limitações e segurança

  • Relatos de que alguns flags (por exemplo, --upload-file) não se traduzem bem.
  • Preocupações com “flags demais” e expansão de recursos; sugestão de um binário separado curl-as-libcurl.
  • Preocupação com “mais C inseguro na internet”, contraposta por:
    • Confiança na maturidade do libcurl.
    • Observação de que o código gerado é simples; o risco real está na lógica adicionada pelo usuário.

Ferramentas e ecossistema relacionados

  • Menções a:
    • Hurl: uma ferramenta de teste em CLI construída sobre libcurl com encadeamento e asserções.
    • Vários conversores de curl→code (web e CLI) e suas implicações de privacidade.
    • Reflexões de que precisar de codegen em si destaca a verbosidade do C versus linguagens como Python/Node.