curl-wget वेन डायग्राम

 (daniel.haxx.se)
2 पॉइंट द्वारा GN⁺ 2023-09-05 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • wget को curl का सीधा प्रतिस्पर्धी नहीं, बल्कि काम के हिसाब से साथ इस्तेमाल किए जा सकने वाले कुछ हद तक overlap करने वाले फीचर्स वाला tool मानना चाहिए
  • चुनाव का आधार tool preference नहीं, बल्कि यह होना चाहिए कि काम पूरा करने के लिए कौन-सा ज़्यादा उपयुक्त है; अगर wget बेहतर फिट है, तो wget इस्तेमाल करें
  • curl और wget के technical differences और overlap वाले हिस्सों को एक नजर में दिखाने के लिए Venn diagram में व्यवस्थित किया गया है, और full-resolution image भी उपलब्ध है
  • दोनों projects टकराव में नहीं हैं; curl की तरफ से wget में code contribute किया गया है और कई wget maintainers भी curl में contribute कर चुके हैं
  • diagram में errors या omissions को update किया जा सकता है, और अलग comparison document व download tools comparison table में ज्यादा detail देखी जा सकती है

curl और wget को देखने का नज़रिया

  • wget, curl का competitor कम और companion tool ज़्यादा है
  • दोनों tools के कुछ features overlap करते हैं, लेकिन मुख्य बात किसी खास tool पर अड़े रहना नहीं, बल्कि जिस काम को solve करना है उसके हिसाब से चुनाव करना है
  • अगर किसी situation में wget काम पूरा करने के लिए ज़्यादा suitable है, तो wget इस्तेमाल करना बेहतर है

Venn diagram में व्यवस्थित differences

  • curl और wget के बीच के technical differences और कुछ similarities को visually दिखाने के लिए Venn diagram बनाया गया है
  • diagram image पर click करने पर full-resolution version देखा जा सकता है
  • अगर कोई problem या missing item मिले तो बताने का अनुरोध है, और ज़रूरत पड़ने पर diagram update किया जा सकता है

projects के बीच collaboration

  • curl की तरफ से wget में code contribute किया गया है
  • कई wget maintainers भी curl में contribute कर चुके हैं
  • दोनों projects का रिश्ता competition या confrontation से ज़्यादा collaboration जैसा है

और देखने लायक comparison resources

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-09-05
Hacker News की राय

  • मुझे लगता है कि Wget वाले हिस्से में कम से कम sensible defaults, resume और error होने पर retry भी शामिल करने चाहिए
    हाल ही में मुझे unstable connection पर एक बहुत बड़ी file download करने के लिए script लिखनी पड़ी, और engineers के बीच आम धारणा थी कि ऐसे काम के लिए Wget इस्तेमाल करना चाहिए
    मैंने curl भी आज़माया, लेकिन default state में resume या retry नहीं हुआ, और manual पढ़कर कई options और arguments specify करने पड़े। लगा कि यह behavior default होना चाहिए
    Wget में crash के बाद तक सहित हर स्थिति में resume enable करने के लिए सिर्फ --continue option काफी था, और manual के introduction में भी लिखा है कि इसे slow या unstable network पर robust तरीके से काम करने के लिए design किया गया है, और download fail होने पर पूरी file मिलने तक retry करता रहता है
    curl में भी खराब connection पर reliably काम करने के लिए सभी options set किए जा सकते हैं, लेकिन Wget में वह default behavior पहले से on लगता है, इसलिए जिन error conditions को मैं खुद test नहीं कर पाया, उनमें भी expected behavior करेगा, इस पर भरोसा होता है। HTTP protocol update होने पर भी नया Wget default रूप से support करने की संभावना रखता है, लेकिन curl में improved behavior enable करने के लिए नया switch चाहिए हो सकता है, और product release के बाद उसे add नहीं किया जा सकता
    मेरे लिए curl एक शानदार और बेहद versatile low-level tool है, और उसका CLI भी उसी nature को reflect करता है, लेकिन रोज़मर्रा के कामों में Wget default state में कहीं बेहतर काम करता है, इसलिए मैं उसे prefer करता हूँ। manual भी जल्दी skim किया जा सकता है, शायद इसलिए कि यह यहाँ बताए गए सभी obscure protocols को support नहीं करता

    • sensible defaults से सहमत हूँ
      सिर्फ wget url से URL download होकर save हो जाता है, command-line use में इसी बात से Wget जीतता है
    • curl में भी ठीक वही feature है। resume के लिए -C flag है, और retry के लिए --retry है
      व्यक्तिगत रूप से मुझे curl के defaults भी काफी sensible लगते हैं, और curl जैसे tool में इन दोनों में से कोई भी चीज default रूप से on नहीं चाहिए
    • Wget में file से URL पढ़ने वाला -i भी जोड़ना चाहिए
      खासकर wget -i - standard input से पढ़ता है, इसलिए pipelines में बहुत काम का है
      मेरी जानकारी में curl यह नहीं कर सकता। आमतौर पर xargs इस्तेमाल करने को कहा जाता है, लेकिन वह सभी URL आने तक इंतज़ार करके curl चलाता है, इसलिए URL generate करने वाली command और download command के बीच की parallelism छोड़नी पड़ती है, जिससे वह replacement के तौर पर थोड़ा awkward है
    • दोनों tools के अपने-अपने use cases हैं। ChatGPT जैसे large language models आने के बाद, कोई भी tool इस्तेमाल करें, सही command-line spell पाना बहुत आसान हो गया है
      पहले manual पढ़ा हो तब भी सही flag याद रखना आसान नहीं होता, और generated command-line को verify करना आमतौर पर manual पढ़कर शुरू से assemble करने से कम मेहनत वाला होता है
      modern web में कभी-कभी अपनी script में Puppeteer जैसे tools इस्तेमाल करना ज्यादा आसान होता है। खासकर अगर जिस site से interact कर रहे हों वह JavaScript-heavy हो तो और भी
    • curl का URL parser wget की तुलना में काफी strict है, यह भी मुझे व्यक्तिगत रूप से खटकता है
      उदाहरण के लिए $ curl -sSLOJ 'example.com/file name.txt' से curl: (3) URL using bad/illegal format or missing URL error आता है, और $ curl -sSLOJ 'example.com/file%20name.txt' file%20name.txt नाम की file बनाता है
      दूसरी ओर wget बिना extra flag के दोनों URL से "file name.txt" नाम की file बनाता है। हालांकि यह example URL 404 है, इसलिए strictly wget में --content-on-error भी लगाना पड़ेगा

  • कई लोगों के लिए मुख्य फर्क शायद default रूप से standard output पर लिखने वाला tool और default रूप से file बनाने वाला tool होगा

    • या default रूप से sh में pipe किया जा सकने वाला tool ;-)

  • मेरे लिए Wget की निर्णायक feature यह है कि यह default रूप से URL से निकले filename के साथ file download करता है
    wget url://to/file.htm चलाने पर current working directory में "file.htm" नाम की file बन जाती है
    curl में curl url://to/file.htm > file.htm जैसा लिखना पड़ता है, या उससे कम convenient कोई और command spell इस्तेमाल करनी पड़ती है

    • curl -O
      https://curl.se/docs/manpage.html#-O
    • बात सही है, लेकिन wget "url://to/file.htm?uid=foo&q=bar&rnd=4" जैसे cases भी होते हैं
    • मैंने इसे हमेशा Wget की गलत feature माना है। general principle यह है कि command-line utility को अलग instruction न हो तो अपना primary result standard output पर लिखना चाहिए
    • curl -O ज्यादा convenient है
      उस “decisive feature” को cat से compare करें तो cat file.html का cat file.html > file.html बन जाना जैसा है। फिर जब असल में copy नहीं बल्कि output चाहिए हो, तो cat file.html -o - जैसा कुछ लिखना पड़ेगा, इसलिए मुझे खुशी है कि curl में ऐसी feature नहीं है

  • Daniel Stenberg उन दुर्लभ developers में हैं जो अपनी creation में दिल और आत्मा लगा देते हैं
    modern Big Tech में shadow जैसे developers money-making machine के replaceable cogs जैसे दिखते हैं, और ऐसी quality धीरे-धीरे गायब होती लगती है
    लगता है वह curl को IT दुनिया में अपनी छोड़ी हुई छाप की तरह treat करते हैं

    • free software ऐसे लोगों से भरा है। इसलिए technical रूप से inferior होने पर भी free software इस्तेमाल करता हूँ
      बेशक आजकल कई मामलों में यह सचमुच technical रूप से बेहतर भी होता है, जिससे choice आसान हो जाती है
    • company में काम करते हुए शायद कोई अपनी creation में दिल न लगाए, लेकिन अगर किसी के पास cash लाने वाला popular personal project हो, तो मुझे लगता है कोई भी उतना dedicated हो जाएगा

  • यह comparison थोड़ा पुराना लगता है। उदाहरण के लिए diagram में Wget side में नीचे वाली दोनों चीजें missing हैं
    HTTP PUT wget --method=PUT --body-data= से possible है, और proxy व HTTPS भी wget --use-proxy=on --https_proxy=[https://example.com](<https://example.com>;) की तरह possible हैं
    curl में consistently ज्यादा options और flexibility हैं, लेकिन Venn diagram के right side में मौजूद कई items में से कुछ Wget भी कुछ हद तक कर सकता है

    • manual page के हिसाब से FTP support भी लगता है

  • वाह, मुझे नहीं पता था कि curl इतने सारे protocols support करता है। फिर भी छोटा intersection area शायद वह हिस्सा है जिसे curl/Wget users में से 90% से ज्यादा लोग असल में इस्तेमाल करते होंगे
    developer के नजरिए से overlapping area इतना बड़ा नहीं है, लेकिन user के नजरिए से यह कहीं बड़ा दिख सकता है

  • article में मुझे सबसे अच्छा यह वाक्य लगा
    “मैंने wget में code contribute किया है। कई wget maintainers ने भी curl में contribute किया है। हम सभी दोस्त हैं।”

  • Daniel Stenberg की बनाई comparison भी जरूर देखनी चाहिए
    https://daniel.haxx.se/docs/curl-vs-wget.html

    • यह नई comparison भी Daniel Stenberg ने बनाई है और उसी domain पर host है, लेकिन curl docs में नहीं, उनके blog पर है

  • पहले जब किसी website को mirror करना होता था तो Wget इस्तेमाल करता था। Wget एक specialized tool है
    curl एक general-purpose request library है जिसके साथ CLI frontend है, और यह दूसरे programs में embed भी होता है या PHP वगैरह की standard library API की तरह इस्तेमाल किया जाता है

    • व्यक्तिगत रूप से mirroring के लिए मुझे httrack पसंद है, लेकिन Wget में href/src conversion feature है, इसलिए कुछ specific goals के लिए कभी-कभी बेहतर fit होता है

  • सबसे common usage शायद दोनों के overlapping हिस्से में होगा। इसलिए मैं ऐसा Venn diagram देखना चाहूँगा जो दिखाए कि कौन-से operating systems और Docker images में कौन-सा tool default रूप से installed है