แผนภาพเวนน์ของ curl-wget

• wget ไม่ได้เป็นคู่แข่งโดยตรงของ curl แต่ควรมองว่าเป็น เครื่องมือที่มีความสามารถบางส่วนทับซ้อนกัน และสามารถใช้ร่วมกันได้ตามลักษณะงาน
• เกณฑ์ในการเลือกไม่ใช่ความชอบต่อเครื่องมือ แต่คือ เหมาะกับการทำงานนั้นให้เสร็จมากกว่าหรือไม่ และถ้า wget เหมาะกว่า ก็ใช้ wget ได้เลย
• มีการสรุปความแตกต่างทางเทคนิคและส่วนที่ทับซ้อนกันของ curl กับ wget แบบเห็นภาพใน แผนภาพเวนน์ และยังมีภาพความละเอียดเต็มให้ด้วย
• ทั้งสองโปรเจ็กต์ไม่ได้อยู่ในความสัมพันธ์แบบเผชิญหน้ากัน โดยฝั่ง curl เคยมีส่วนร่วมส่งโค้ดให้ wget และ ผู้ดูแล wget หลายคนก็เคยมีส่วนร่วมกับ curl เช่นกัน
• ข้อผิดพลาดหรือสิ่งที่ตกหล่นในแผนภาพสามารถอัปเดตได้ และยังมีเอกสารเปรียบเทียบแยกต่างหากกับตารางเปรียบเทียบเครื่องมือดาวน์โหลดให้ดูรายละเอียดเพิ่มเติม

---

เกณฑ์ในการมอง curl และ wget

• wget ใกล้เคียงกับการเป็น เครื่องมือคู่กัน มากกว่าจะเป็นคู่แข่งของ curl
• เครื่องมือทั้งสองมีฟีเจอร์บางส่วนที่ทับซ้อนกัน แต่ประเด็นสำคัญไม่ใช่การยึดติดกับเครื่องมือใดเครื่องมือหนึ่ง แต่คือการเลือกให้เหมาะกับ งานที่ต้องการแก้ไข
• หากในบางสถานการณ์ wget เหมาะกับการทำงานนั้นให้เสร็จมากกว่า ก็เลือกใช้ wget จะดีกว่า

ความแตกต่างที่สรุปด้วยแผนภาพเวนน์

• มีการสร้างแผนภาพเวนน์เพื่อแสดงให้เห็น ความแตกต่างทางเทคนิค และความคล้ายคลึงกันบางส่วนระหว่าง curl กับ wget ในรูปแบบภาพ
• สามารถคลิกที่ภาพแผนภาพเพื่อดูเวอร์ชันความละเอียดเต็มได้
• ผู้เขียนขอให้แจ้งหากพบปัญหาหรือรายการที่ตกหล่น และสามารถอัปเดตแผนภาพได้หากจำเป็น

ความร่วมมือระหว่างโปรเจ็กต์

• ฝั่ง curl เคยมีส่วนร่วมส่งโค้ดให้ wget
• ผู้ดูแล wget หลายคนก็เคยมีส่วนร่วมกับ curl
• ความสัมพันธ์ของทั้งสองโปรเจ็กต์ใกล้เคียงกับความร่วมมือ มากกว่าการแข่งขันหรือการเผชิญหน้า

แหล่งข้อมูลเปรียบเทียบเพิ่มเติม

• curl vs wget: เอกสารเปรียบเทียบ curl กับ wget
• Compare curl with other download tools: ตารางเปรียบเทียบ curl กับเครื่องมือดาวน์โหลดอื่น ๆ
• OpenHub’s curl vs wget table: ตารางเปรียบเทียบ curl กับ wget ของ OpenHub

[GN⁺]

ความคิดเห็นบน Hacker News

• ผมคิดว่าฝั่ง Wget อย่างน้อยควรใส่เรื่อง ค่าเริ่มต้นที่สมเหตุสมผล, การดาวน์โหลดต่อจากเดิม และการลองใหม่เมื่อเกิดข้อผิดพลาดไว้ด้วย
  ช่วงหลังมานี้ผมต้องเขียนสคริปต์เพื่อดาวน์โหลดไฟล์ขนาดใหญ่มากผ่านการเชื่อมต่อที่ไม่เสถียร และความเข้าใจร่วมกันในหมู่วิศวกรคือ งานแบบนี้ควรใช้ Wget
  ผมลองใช้ curl ด้วย แต่โดยค่าเริ่มต้นมันไม่ดาวน์โหลดต่อจากเดิมหรือ retry ให้ ต้องอ่านคู่มือแล้วระบุออปชันกับอาร์กิวเมนต์หลายอย่าง ผมรู้สึกว่าพฤติกรรมแบบนี้ควรเป็นค่าเริ่มต้น
  สำหรับ Wget แค่ใช้ออปชัน --continue ตัวเดียวก็เปิดการดาวน์โหลดต่อได้ในทุกสถานการณ์ รวมถึงหลังโปรแกรมล่ม และในบทนำของคู่มือก็ระบุว่าออกแบบมาให้ทำงานทนทานบนเครือข่ายที่ช้าหรือไม่เสถียร หากดาวน์โหลดล้มเหลวก็จะพยายามใหม่ต่อไปจนกว่าจะได้ไฟล์ครบ
  ด้วย curl ก็น่าจะตั้งออปชันทั้งหมดให้ทำงานได้อย่างเชื่อถือได้บนการเชื่อมต่อแย่ ๆ ได้ แต่ Wget ดูเหมือนเปิดพฤติกรรมพื้นฐานเหล่านั้นไว้อยู่แล้ว ทำให้ผมเชื่อได้ว่ามันจะทำงานตามที่คาดในสถานการณ์ผิดพลาดที่ผมไม่ได้ทดสอบเอง แม้โปรโตคอล HTTP จะอัปเดต Wget เวอร์ชันใหม่ก็มีโอกาสรองรับเป็นค่าเริ่มต้น แต่ curl อาจต้องใช้สวิตช์ใหม่เพื่อเปิดพฤติกรรมที่ดีขึ้น และหลังปล่อยผลิตภัณฑ์ไปแล้วก็เพิ่มไม่ได้
  สำหรับผม curl เป็น เครื่องมือระดับล่าง ที่ยอดเยี่ยมและอเนกประสงค์มาก และ CLI ของมันก็สะท้อนลักษณะนั้น แต่ในงานประจำวันผมชอบ Wget มากกว่า เพราะมันทำงานได้ดีกว่ามากตั้งแต่ค่าเริ่มต้น คู่มือก็ไล่อ่านได้เร็วกว่า อาจเพราะไม่ได้รองรับโปรโตคอลลึกลับทั้งหมดที่พูดถึงกันที่นี่

  • เห็นด้วยเรื่อง ค่าเริ่มต้นที่สมเหตุสมผล
    แค่ wget url แล้วดาวน์โหลด URL มาเก็บได้ ก็ทำให้ Wget ชนะในการใช้งานบรรทัดคำสั่งแล้วในความเห็นผม
  • curl ก็มีฟังก์ชันนั้นตรง ๆ เหมือนกัน การดาวน์โหลดต่อคือแฟล็ก -C และการ retry คือ --retry
    โดยส่วนตัวผมรู้สึกว่าค่าเริ่มต้นของ curl ก็สมเหตุสมผลพอสมควร และสำหรับเครื่องมืออย่าง curl ผมไม่อยากให้ทั้งสองอย่างนั้นเปิดเป็นค่าเริ่มต้น
  • ควรเพิ่ม -i ของ Wget ที่ให้อ่าน URL จากไฟล์ได้ด้วย
    โดยเฉพาะ wget -i - มีประโยชน์มากใน pipeline เพราะมันอ่านจาก standard input
    เท่าที่ผมรู้ curl ทำแบบนี้ไม่ได้ ปกติมักบอกให้ใช้ xargs แต่แบบนั้นต้องรอให้ URL มาครบทั้งหมดก่อนแล้วค่อยรัน curl ทำให้เสียความขนานระหว่างคำสั่งที่สร้าง URL กับคำสั่งดาวน์โหลด จึงยังไม่ค่อยเหมาะจะเป็นตัวทดแทน
  • ทั้งสองเครื่องมือต่างก็มีกรณีใช้งานของตัวเอง ผมคิดว่าการมาของ โมเดลภาษาขนาดใหญ่ อย่าง ChatGPT ทำให้ไม่ว่าจะใช้เครื่องมือไหน ก็หาคำสั่ง command line ที่เหมาะสมได้ง่ายขึ้นมาก
    ต่อให้เคยอ่านคู่มือมาแล้ว ก็ไม่ง่ายที่จะจำแฟล็กที่ต้องการได้เป๊ะ ๆ และโดยปกติการตรวจสอบคำสั่งที่ถูกสร้างขึ้นมาจะเหนื่อยน้อยกว่าการอ่านคู่มือแล้วประกอบคำสั่งเองตั้งแต่ต้น
    บนเว็บยุคใหม่ บางครั้งใช้เครื่องมืออย่าง Puppeteer ในสคริปต์ที่เขียนเองยังง่ายกว่า โดยเฉพาะถ้าไซต์ที่ต้องโต้ตอบด้วยใช้ JavaScript หนักมาก
  • อีกจุดที่ส่วนตัวผมรำคาญคือ ตัวแยกวิเคราะห์ URL ของ curl เข้มงวดกว่า 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 จะสร้างไฟล์ชื่อ "file name.txt" จาก URL ทั้งสองแบบโดยไม่ต้องมีแฟล็กเพิ่ม อย่างไรก็ตาม URL ตัวอย่างนี้เป็น 404 ดังนั้นถ้าจะพูดให้เคร่งครัดต้องใส่ --content-on-error ให้ wget ด้วย

• สำหรับหลายคน ความต่างหลักน่าจะเป็น เครื่องมือที่เขียนลง standard output เป็นค่าเริ่มต้น กับ เครื่องมือที่สร้างไฟล์เป็นค่าเริ่มต้น

  • หรือเครื่องมือที่โดยค่าเริ่มต้นสามารถ pipe เข้า 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 เพราะหลักการทั่วไปคือ utility บน command line ควรเขียนผลลัพธ์หลักไปที่ standard output ถ้าไม่ได้สั่งเป็นอย่างอื่น
  • curl -O สะดวกกว่า
    ถ้าเทียบ “ฟีเจอร์ชี้ขาด” นั้นกับ cat ก็เหมือน cat file.html ถูกเปลี่ยนเป็น cat file.html > file.html แล้วเวลาที่อยากแค่พิมพ์ออกมา ไม่ใช่คัดลอกจริง ๆ ก็ต้องใช้ประมาณ cat file.html -o - ดังนั้นผมดีใจที่ curl ไม่มีฟีเจอร์แบบนั้น

• Daniel Stenberg จัดอยู่ในกลุ่มนักพัฒนาที่หาได้ยากซึ่งทุ่มเท หัวใจและจิตวิญญาณ ให้กับผลงานของตัวเอง
  ในบิ๊กเทคยุคใหม่ นักพัฒนาที่เหมือนเงาดูราวกับเป็นฟันเฟืองที่เปลี่ยนได้ของเครื่องจักรทำเงิน และคุณลักษณะแบบนี้ดูเหมือนกำลังหายไปเรื่อย ๆ
  เขาดูเหมือนปฏิบัติต่อ curl ราวกับเป็นร่องรอยของตัวเองที่ทิ้งไว้ในโลก IT

  • ซอฟต์แวร์เสรีมีคนแบบนี้เต็มไปหมด นั่นจึงเป็นเหตุผลที่ผมใช้ซอฟต์แวร์เสรี แม้มันจะด้อยกว่าในเชิงเทคนิคก็ตาม
    แน่นอนว่าทุกวันนี้หลายครั้งมันดีกว่าในเชิงเทคนิคจริง ๆ ด้วย ทำให้เลือกง่ายขึ้น
  • ถ้าทำงานในบริษัท คุณอาจไม่ได้ทุ่มใจให้ผลงานของตัวเองก็ได้ แต่ถ้ามีโปรเจกต์ส่วนตัวที่ได้รับความนิยมและทำเงินสดให้มาก ผมว่าทุกคนก็คงทุ่มเทได้ขนาดนั้นเหมือนกัน

• การเปรียบเทียบนี้ดูจะเก่าไปนิด ตัวอย่างเช่น ในไดอะแกรมฝั่ง Wget ขาดสองอย่างด้านล่างนี้
  HTTP PUT ทำได้ด้วย wget --method=PUT --body-data= และพร็อกซีกับ HTTPS ก็ทำได้เช่น wget --use-proxy=on --https_proxy=[https://example.com](<https://example.com>;)
  curl มีออปชันและความยืดหยุ่นมากกว่าอย่างสม่ำเสมอ แต่หลายรายการทางขวาของแผนภาพเวนน์นั้น Wget ก็ทำได้ในระดับหนึ่ง

  • ดูจาก man page แล้วน่าจะมี การรองรับ FTP ด้วย

• ว้าว ไม่รู้เลยว่า curl รองรับ โปรโตคอล มากขนาดนี้ ถึงอย่างนั้น ส่วนทับซ้อนเล็ก ๆ นั้นก็น่าจะเป็นส่วนที่ผู้ใช้ curl/Wget มากกว่า 90% ใช้งานจริง
  จากมุมมองนักพัฒนา พื้นที่ที่ซ้อนกันอาจไม่ได้ใหญ่มาก แต่จากมุมมองผู้ใช้ มันอาจดูใหญ่กว่ามาก

• ส่วนที่ผมชอบที่สุดในบทความคือประโยคนี้
  “ผมเคย contribute โค้ดให้ wget ผู้ดูแล wget หลายคนก็เคย contribute ให้ curl เราทุกคนเป็นเพื่อนกัน”

• การเปรียบเทียบที่ Daniel Stenberg ทำไว้ก็เป็นสิ่งที่ควรอ่าน
  https://daniel.haxx.se/docs/curl-vs-wget.html

  • การเปรียบเทียบใหม่นี้ก็ทำโดย Daniel Stenberg เช่นกัน และโฮสต์อยู่บนโดเมนเดียวกัน แต่ไม่ได้อยู่ในเอกสารของ curl แต่อยู่บนบล็อกของเขา

• เมื่อก่อนเวลาต้องการ mirror เว็บไซต์ ผมใช้ Wget เพราะ Wget เป็นเครื่องมือเฉพาะทาง
  curl เป็นไลบรารีร้องขอแบบอเนกประสงค์ที่มี CLI frontend และยังถูกฝังในโปรแกรมอื่น หรือใช้เหมือน API ของไลบรารีมาตรฐานใน PHP เป็นต้น

  • โดยส่วนตัวผมชอบ httrack สำหรับการ mirror แต่ Wget มีฟีเจอร์แปลง href/src ซึ่งบางครั้งเหมาะกับเป้าหมายบางอย่างมากกว่า

• การใช้งานที่พบบ่อยที่สุดน่าจะเป็นส่วนที่ทั้งสองทับซ้อนกัน ดังนั้นผมอยากเห็นแผนภาพเวนน์ที่แสดงว่าแต่ละเครื่องมือถูกติดตั้งมาเป็นค่าเริ่มต้นใน ระบบปฏิบัติการและ Docker image ใดบ้าง