Diagrama de Venn curl-wget

 (daniel.haxx.se)
2 pontos por GN⁺ 2023-09-05 | 1 comentários | Compartilhar no WhatsApp
  • O wget não deve ser visto como um concorrente direto do curl, mas como uma ferramenta com funcionalidades parcialmente sobrepostas que pode ser usada em conjunto, dependendo da tarefa
  • O critério de escolha não é a preferência por uma ferramenta, e sim qual é mais adequada para concluir a tarefa; se o wget for mais apropriado, use o wget
  • As diferenças técnicas e as áreas de sobreposição entre curl e wget foram organizadas em um diagrama de Venn para facilitar a visualização, e uma imagem em resolução completa também é fornecida
  • Os dois projetos não são adversários; o lado do curl já contribuiu código para o wget, e vários mantenedores do wget também já contribuíram para o curl
  • Erros ou omissões no diagrama podem ser atualizados, e é possível consultar mais detalhes em um documento comparativo separado e em uma tabela de comparação de ferramentas de download

Critérios para avaliar curl e wget

  • O wget é mais uma ferramenta complementar do que um concorrente do curl
  • As duas ferramentas têm algumas funcionalidades em comum, mas o ponto principal não é insistir em uma ferramenta específica, e sim fazer uma escolha adequada à tarefa que se quer resolver
  • Se, em determinada situação, o wget for mais adequado para concluir a tarefa, é melhor usar o wget

Diferenças organizadas em um diagrama de Venn

  • Foi criado um diagrama de Venn para mostrar visualmente as diferenças técnicas e algumas semelhanças entre curl e wget
  • Ao clicar na imagem do diagrama, é possível ver a versão em resolução completa
  • O autor pede que problemas ou itens ausentes sejam informados, e o diagrama pode ser atualizado se necessário

Colaboração entre os projetos

  • O lado do curl já contribuiu código para o wget
  • Vários mantenedores do wget também já contribuíram para o curl
  • A relação entre os dois projetos é mais próxima de colaboração do que de competição ou oposição

Outros materiais comparativos interessantes

Leituras relacionadas

1 comentários

 
GN⁺ 2023-09-05
Comentários do Hacker News

  • Acho que, do lado do Wget, deveriam colocar pelo menos padrões sensatos, retomada de downloads e novas tentativas em caso de erro
    Recentemente tive que escrever um script para baixar um arquivo enorme em uma conexão instável, e o senso comum entre os engenheiros era que, para esse tipo de tarefa, se deveria usar Wget
    Também testei curl, mas, no estado padrão, ele não retomava nem tentava de novo; foi preciso ler o manual e especificar várias opções e argumentos. Sinto que esse comportamento deveria vir por padrão
    No Wget, bastou uma única opção, --continue, para ativar a retomada em todas as situações, inclusive após uma falha; e a introdução do manual diz que ele foi projetado para operar de forma robusta em redes lentas ou instáveis, continuando a tentar novamente se o download falhar até obter o arquivo inteiro
    Com curl provavelmente dá para ajustar todas as opções para ele funcionar de forma confiável em conexões ruins, mas o Wget parece já vir com esse comportamento básico ativado, o que me dá confiança de que ele vai agir como esperado mesmo em cenários de erro que eu não consegui testar diretamente. Mesmo que o protocolo HTTP seja atualizado, é possível que um Wget novo dê suporte a isso por padrão, enquanto o curl talvez precise de uma nova chave para ativar o comportamento aprimorado, algo que não dá para adicionar depois do lançamento do produto
    Para mim, curl é uma ferramenta de baixo nível excelente e muito versátil, e a CLI reflete essa natureza; mas, para tarefas do dia a dia, prefiro Wget porque funciona muito melhor no estado padrão. O manual também é mais rápido de folhear, provavelmente porque não dá suporte a todos aqueles protocolos obscuros mencionados aqui

    • Concordo com padrões sensatos
      Só o fato de wget url baixar e salvar a URL já faz o Wget vencer no uso pela linha de comando, na minha opinião
    • curl tem exatamente essa funcionalidade. A retomada é a flag -C, e as novas tentativas são --retry
      Pessoalmente, também acho os padrões do curl bem sensatos, e não gostaria que nenhuma dessas duas coisas viesse ativada por padrão em uma ferramenta como o curl
    • Também deveria ser adicionado ao Wget o -i, que permite ler URLs de um arquivo
      Em especial, wget -i - lê da entrada padrão, por isso é muito útil em pipelines
      Pelo que sei, o curl não faz isso. Normalmente dizem para usar xargs, mas ele espera todas as URLs chegarem antes de executar o curl, então você abre mão do paralelismo entre o comando que gera as URLs e o comando que faz o download; como substituto, é meio inadequado
    • As duas ferramentas têm seus respectivos usos. Com o surgimento de grandes modelos de linguagem como o ChatGPT, acho que ficou muito mais fácil obter o encantamento correto de linha de comando, qualquer que seja a ferramenta usada
      Mesmo que você já tenha lido o manual antes, não é fácil lembrar exatamente a flag desejada, e verificar uma linha de comando gerada costuma dar menos trabalho do que montar tudo do zero lendo o manual
      Na web moderna, às vezes é mais fácil usar ferramentas como Puppeteer em scripts próprios. Isso é especialmente verdade se o site com que você está interagindo usa muito JavaScript
    • Outra coisa que pessoalmente me incomoda é que o parser de URL do curl é muito mais rigoroso que o do wget
      Por exemplo, $ curl -sSLOJ 'example.com/file name.txt' gera o erro curl: (3) URL using bad/illegal format or missing URL, e $ curl -sSLOJ 'example.com/file%20name.txt' cria um arquivo chamado file%20name.txt
      Já o wget cria um arquivo chamado "file name.txt" a partir das duas URLs, sem flags adicionais. Dito isso, como essa URL de exemplo dá 404, a rigor também seria preciso passar --content-on-error ao wget

  • Para muita gente, a diferença essencial provavelmente é entre uma ferramenta que escreve na saída padrão por padrão e uma ferramenta que cria um arquivo por padrão

    • Ou uma ferramenta que, por padrão, pode ser encadeada com pipe para sh ;-)

  • Para mim, a funcionalidade decisiva do Wget é que, por padrão, ele baixa para um arquivo com um nome derivado da URL
    Se você executa wget url://to/file.htm, aparece no diretório de trabalho atual um arquivo chamado "file.htm"
    Com curl, é preciso escrever algo como curl url://to/file.htm > file.htm, ou algum outro encantamento menos conveniente

    • curl -O
      https://curl.se/docs/manpage.html#-O
    • É, mas há casos como wget "url://to/file.htm?uid=foo&q=bar&rnd=4"
    • Sempre vi isso como um recurso equivocado do Wget, por causa do princípio geral de que utilitários de linha de comando devem escrever seu resultado principal na saída padrão se não houver instrução em contrário
    • curl -O é mais conveniente
      Comparando esse “recurso decisivo” com cat, seria como cat file.html virar cat file.html > file.html. Então, quando você realmente quisesse imprimir em vez de copiar, teria que usar algo como cat file.html -o -; por isso acho bom que o curl não tenha esse recurso

  • Daniel Stenberg pertence a uma rara categoria de desenvolvedores que colocam coração e alma na própria criação
    Nas big techs modernas, desenvolvedores meio sombrios parecem engrenagens substituíveis de máquinas de fazer dinheiro, e esse tipo de característica parece estar desaparecendo cada vez mais
    Ele parece tratar o curl como sua marca deixada no mundo de TI

    • O software livre está cheio de pessoas assim. É por isso que uso software livre mesmo quando é tecnicamente inferior
      Claro que, hoje em dia, em muitos casos ele é de fato tecnicamente melhor, o que torna a escolha mais fácil
    • Quando você trabalha em uma empresa, talvez não coloque tanto coração na própria criação; mas, se tiver um projeto pessoal popular que rende bastante dinheiro, acho que qualquer um se dedicaria nesse nível

  • Esta comparação parece um pouco desatualizada. Por exemplo, no diagrama faltam estes dois itens do lado do Wget
    HTTP PUT é possível com wget --method=PUT --body-data=, e proxy e HTTPS também são possíveis, como em wget --use-proxy=on --https_proxy=[https://example.com](<https://example.com>;)
    O curl tem consistentemente mais opções e flexibilidade, mas entre os vários itens do lado direito do diagrama de Venn há coisas que o Wget também consegue fazer em alguma medida

    • Pela página de manual, parece que também há suporte a FTP

  • Uau, eu não sabia que o curl dava suporte a tantos protocolos. Ainda assim, a pequena área de interseção provavelmente é a parte que mais de 90% dos usuários de curl/Wget realmente usam
    Do ponto de vista de um desenvolvedor, a área de sobreposição não é tão grande, mas, do ponto de vista do usuário, ela pode parecer muito maior

  • A melhor parte do texto, para mim, foi esta frase
    “Eu já contribuí código para o wget. Vários mantenedores do wget também contribuíram para o curl. Somos todos amigos.”

  • A comparação feita por Daniel Stenberg também é leitura obrigatória
    https://daniel.haxx.se/docs/curl-vs-wget.html

    • Esta nova comparação também foi feita por Daniel Stenberg e está hospedada no mesmo domínio, mas está no blog dele, não na documentação do curl

  • Antigamente, quando eu queria espelhar um site, usava Wget. Wget é uma ferramenta especializada
    curl é uma biblioteca de requisições de uso geral com uma interface CLI, e também é embutido em outros programas ou usado como API de biblioteca padrão em PHP e afins

    • Pessoalmente, gosto do httrack para espelhamento, mas o Wget tem recurso de conversão de href/src, então às vezes se encaixa melhor em certos objetivos

  • O uso mais comum deve estar na interseção entre os dois. Por isso, gostaria de ver um diagrama de Venn mostrando em quais sistemas operacionais e imagens Docker cada ferramenta vem instalada por padrão