curl-wget ベン図

 (daniel.haxx.se)
2 ポイント 投稿者 GN⁺ 2023-09-05 | 1件のコメント | WhatsAppで共有
  • wget は curl の直接的な競合相手ではなく、作業に応じて併用できる 一部の機能が重なるツール と見るべき
  • 選択基準はツールの好みではなく、作業を終えるのにより適しているか であり、wget のほうが適しているなら wget を使えばよい
  • curl と wget の技術的な違いと重なる領域をひと目で分かるように ベン図 で整理しており、フル解像度の画像も提供されている
  • 両プロジェクトは対立関係ではなく、curl 側から wget にコードを貢献しており、複数の wget メンテナー も curl に貢献したことがある
  • 図の誤りや抜けは更新される可能性があり、別の比較文書やダウンロードツール比較表でより詳しく確認できる

curl と wget を見る基準

  • wget は curl の競合相手というより 補完的なツール に近い
  • 2 つのツールは一部の機能が重なるが、重要なのは特定のツールにこだわることではなく、解決したい作業 に合った選択をすること
  • ある状況で wget のほうが作業を終えるのに適しているなら、wget を使うのがよい

ベン図で整理した違い

  • curl と wget の間の 技術的な違い と一部の類似点を視覚的に示すために、ベン図を作成した
  • 図の画像はクリックするとフル解像度版を見られる
  • 問題や抜けている項目が見つかったら知らせてほしいとしており、必要なら図を更新できる

プロジェクト間の協力

  • curl 側から wget にコードを貢献したことがある
  • 複数の wget メンテナー も curl に貢献したことがある
  • 両プロジェクトの関係は、競争や対立よりも協力に近い

さらに見る価値のある比較資料

関連記事

1件のコメント

 
GN⁺ 2023-09-05
Hacker News のコメント

  • Wget 側には少なくとも 合理的なデフォルト設定、レジューム、エラー時のリトライも入れるべきだと思う
    最近、不安定な接続で非常に大きなファイルを受信するスクリプトを書く必要があったが、エンジニアの間での共通認識は、この種の作業には Wget を使うべきというものだった
    curl も試したが、デフォルト状態ではレジュームやリトライが効かず、マニュアルを読んで複数のオプションや引数を指定する必要があった。こうした動作はデフォルトで有効になっているべきだと感じる
    Wget はクラッシュ後まで含めて、あらゆる状況でレジュームを有効にするのに --continue オプション 1 つで済み、マニュアルの紹介にも、遅いまたは不安定なネットワークで堅牢に動作するよう設計されており、ダウンロードが失敗した場合はファイル全体を受け取るまで再試行し続けると書かれている
    curl でも悪い接続で信頼性高く動くようにすべてのオプションを調整することはできるだろうが、Wget はそのようなデフォルト動作がすでに有効になっているように見えるので、自分で試せていない障害状況でも期待どおりに動くと信じやすい。HTTP プロトコルが更新されても、新しい Wget ならデフォルトで対応する可能性があるが、curl は改善された動作を有効にするために新しいスイッチが必要になるかもしれず、製品リリース後には追加できない
    私にとって curl は素晴らしく非常に多用途な 低レベルツール であり、CLI もその性格を反映しているが、日常作業では Wget のほうがデフォルト状態ではるかによく動くので好んでいる。マニュアルもより早く読み流せるが、それはおそらく、ここで言及されている難解なプロトコル群をすべてサポートしていないからだろう

    • 合理的なデフォルト設定 には同意する
      wget url だけで URL をダウンロードして保存するという点だけでも、コマンドライン利用では Wget に軍配が上がると思う
    • curl にもまさにその機能がある。レジュームは -C フラグで、リトライは --retry がある
      個人的には curl のデフォルトもかなり合理的だと感じるし、curl のようなツールでそのどちらかがデフォルトで有効になっていてほしいとは思わない
    • Wget がファイルから URL を読み込める -i も追加すべきだ
      特に wget -i - は標準入力から読むので、パイプラインでとても便利だ
      curl は私の知る限りこれができない。普通は xargs を使えと言われるが、URL がすべて到着するまで待ってから curl を実行するため、URL 生成コマンドとダウンロードコマンドの間の並列性を捨てることになり、代替としてはいまひとつだ
    • どちらのツールにもそれぞれの用途がある。ChatGPT のような 大規模言語モデル が登場したことで、どのツールを使うにしても適切なコマンドライン呪文を得るのがずっと簡単になったと思う
      以前にマニュアルを読んでいたとしても、欲しいフラグを正確に覚えているのは簡単ではなく、生成されたコマンドラインを検証するほうが、マニュアルを読みながら一から組み立てるよりたいてい手間が少ない
      現代の Web では、自作スクリプトで Puppeteer のようなツールを使うほうが簡単なこともある。特にインタラクティブなサイトが JavaScript を多用しているならなおさらだ
    • curl の URL パーサー が wget よりずっと厳格なのも、個人的には気になる点だ
      たとえば $ curl -sSLOJ 'example.com/file name.txt' は curl: (3) URL using bad/illegal format or missing URL というエラーになり、$ curl -sSLOJ 'example.com/file%20name.txt' は file%20name.txt というファイルを作る
      一方 wget は追加フラグなしでどちらの URL でも "file name.txt" というファイルを作る。ただし、この例の URL は 404 なので、厳密には wget に --content-on-error も付ける必要がある

  • 多くの人にとっての核心的な違いは、おそらく デフォルトで標準出力に書くツール と デフォルトでファイルを作るツール の違いだろう

    • あるいは、デフォルトで sh にパイプできるツール ;-)

  • 私にとって Wget の決定的な機能は、デフォルトで URL から導出したファイル名 でファイルをダウンロードすることだ
    wget url://to/file.htm を実行すると、現在の作業ディレクトリに "file.htm" というファイルができる
    curl では curl url://to/file.htm > file.htm のように書くか、それより不便な別の呪文を使う必要がある

    • curl -O
      https://curl.se/docs/manpage.html#-O
    • そうではあるが、wget "url://to/file.htm?uid=foo&q=bar&rnd=4" のようなケースがある
    • 私はずっとこれを Wget の間違った機能だと考えてきた。コマンドラインユーティリティは、別途指示がない限り主結果を 標準出力 に書くべきだという一般原則があるからだ
    • curl -O のほうが便利だ
      その「決定的機能」を cat にたとえると、cat file.html が cat file.html > file.html に変わるようなものだ。そうなると、実際にはコピーではなく出力したいときに cat file.html -o - のようなものを書かなければならず、curl にそういう機能がなくてよかったと思う

  • Daniel Stenberg は、自分の創作物に 心血を注ぐ 稀有な開発者の部類に入る
    現代のビッグテックでは、影のような開発者たちが金を生む機械の交換可能な歯車のように見え、そのような特性は次第に失われつつあるように思える
    彼は curl を、IT 世界に残す自分の足跡のように扱っているようだ

    • 自由ソフトウェアにはこういう人が大勢いる。だからこそ、技術的に劣っていても自由ソフトウェアを使う
      もちろん最近では、実際に技術的にも優れていることが多く、選択はさらに容易になっている
    • 会社で働いていれば自分の創作物に心を注がないこともあるだろうが、現金を大量に生み出す人気の個人プロジェクトがあれば、誰だってそれだけ献身するようになると思う

  • この比較は少し古いようだ。たとえば、図で Wget 側に以下の 2 つが抜けている
    HTTP PUT は wget --method=PUT --body-data= で可能で、プロキシと HTTPS も wget --use-proxy=on --https_proxy=[https://example.com](<https://example.com>;) のように使える
    curl のほうが一貫してオプション数も柔軟性も上だが、ベン図の右側にある項目のうち Wget でもある程度可能なものはいくつかある

    • マニュアルページを見る限り、FTP サポート もあるようだ

  • へえ、curl がこれほど多くの プロトコル をサポートしているとは知らなかった。それでも小さな共通部分こそ、おそらく curl/Wget ユーザーの 90% 以上が実際に使う部分だろう
    開発者の観点では重なりはそれほど大きくないが、ユーザーの観点ではずっと大きく見えるかもしれない

  • 記事でいちばん良かった部分はこの一文だ
    「私は wget にコードを寄稿したことがある。何人かの wget メンテナーも curl に寄稿した。私たちは皆友人だ。」

  • Daniel Stenberg が作った比較も必見だ
    https://daniel.haxx.se/docs/curl-vs-wget.html

    • この新しい比較も Daniel Stenberg が作ったもので、同じドメインにホストされているが、curl のドキュメントではなく彼のブログに載っている

  • 昔は Web サイトを ミラーリング したいときに Wget を使っていた。Wget は特化型ツールだ
    curl は CLI フロントエンド付きの汎用リクエストライブラリで、他のプログラムに組み込まれたり、PHP などの標準ライブラリ API のように使われたりもする

    • 個人的にはミラーリングには httrack が好きだが、Wget には href/src 変換機能があるので、特定の目的ではときどきそちらのほうが向いていることがある

  • 最も一般的な使い方は、たぶん両者の重なる部分だろう。だから、それぞれのツールがどの オペレーティングシステムと Docker イメージ にデフォルトでインストールされているかを示すベン図を見てみたい