2 điểm bởi GN⁺ 2023-09-05 | 1 bình luận | Chia sẻ qua WhatsApp
  • wget không phải là đối thủ cạnh tranh trực tiếp của curl; nên xem nó là một công cụ có một phần chức năng chồng lấn và có thể dùng cùng tùy theo tác vụ
  • Tiêu chí lựa chọn không phải là sở thích công cụ, mà là công cụ nào phù hợp hơn để hoàn thành công việc; nếu wget phù hợp hơn thì cứ dùng wget
  • Các khác biệt kỹ thuật và vùng chồng lấn giữa curl và wget đã được tóm tắt bằng sơ đồ Venn để dễ nhìn, đồng thời cũng có ảnh độ phân giải đầy đủ
  • Hai dự án không ở thế đối đầu; phía curl từng đóng góp mã cho wget, và nhiều maintainer của wget cũng từng đóng góp cho curl
  • Các lỗi hoặc thiếu sót trong sơ đồ có thể được cập nhật; có thể xem chi tiết hơn trong tài liệu so sánh riêng và bảng so sánh các công cụ tải xuống

Tiêu chí nhìn nhận curl và wget

  • wget gần với một công cụ đồng hành hơn là đối thủ của curl
  • Hai công cụ có một phần chức năng chồng lấn, nhưng điều cốt lõi không phải là khăng khăng dùng một công cụ cụ thể, mà là chọn công cụ phù hợp với tác vụ cần giải quyết
  • Trong tình huống wget phù hợp hơn để hoàn thành công việc, nên dùng wget

Tóm tắt khác biệt bằng sơ đồ Venn

  • Một sơ đồ Venn đã được tạo để trực quan hóa các khác biệt kỹ thuật và một số điểm tương đồng giữa curl và wget
  • Có thể nhấp vào ảnh sơ đồ để xem phiên bản độ phân giải đầy đủ
  • Tác giả đề nghị thông báo nếu phát hiện vấn đề hoặc mục bị thiếu, và có thể cập nhật sơ đồ khi cần

Hợp tác giữa các dự án

  • Phía curl từng đóng góp mã cho wget
  • Nhiều maintainer của wget cũng từng đóng góp cho curl
  • Mối quan hệ giữa hai dự án gần với hợp tác hơn là cạnh tranh hay đối đầu

Các tài liệu so sánh đáng xem thêm

1 bình luận

 
GN⁺ 2023-09-05
Ý kiến trên Hacker News
  • Tôi nghĩ phía Wget ít nhất cũng nên có các giá trị mặc định hợp lý, tiếp tục tải, và thử lại khi gặp lỗi
    Gần đây tôi phải viết một script để tải một tệp rất lớn qua kết nối không ổn định, và nhận thức chung giữa các kỹ sư là với việc như vậy thì nên dùng Wget
    Tôi cũng đã thử curl, nhưng mặc định nó không tiếp tục tải hay thử lại; tôi phải đọc hướng dẫn và chỉ định nhiều tùy chọn, tham số. Tôi cảm thấy những hành vi này nên là mặc định
    Với Wget, chỉ cần một tùy chọn --continue là bật được việc tiếp tục tải trong mọi tình huống, kể cả sau khi bị crash; phần giới thiệu trong hướng dẫn cũng nói rằng nó được thiết kế để hoạt động vững vàng trên mạng chậm hoặc không ổn định, và nếu tải thất bại thì sẽ tiếp tục thử lại cho đến khi nhận được toàn bộ tệp
    Với curl, có lẽ cũng có thể chỉnh đủ mọi tùy chọn để nó hoạt động đáng tin cậy trên kết nối kém, nhưng Wget dường như đã bật sẵn kiểu hành vi mặc định đó, khiến tôi tin rằng nó sẽ làm đúng như kỳ vọng ngay cả trong các tình huống lỗi mà tôi chưa tự kiểm thử. Dù giao thức HTTP được cập nhật, Wget mới có khả năng sẽ hỗ trợ mặc định, còn curl có thể cần một switch mới để bật hành vi cải tiến, mà sau khi sản phẩm đã phát hành thì tôi không thể thêm vào được
    Với tôi, curl là một công cụ cấp thấp tuyệt vời và cực kỳ đa năng, CLI của nó cũng phản ánh điều đó, nhưng trong công việc hằng ngày tôi thích Wget hơn vì mặc định nó hoạt động tốt hơn nhiều. Hướng dẫn của nó cũng có thể lướt nhanh hơn, có lẽ vì nó không hỗ trợ tất cả các giao thức khó hiểu được nhắc đến ở đây

    • Tôi đồng ý về các giá trị mặc định hợp lý
      Chỉ riêng việc wget url tải URL xuống và lưu lại cũng đủ để tôi thấy Wget thắng trong cách dùng dòng lệnh
    • curl cũng có đúng chức năng đó. Tiếp tục tải là flag -C, còn thử lại là --retry
      Cá nhân tôi thấy mặc định của curl cũng khá hợp lý, và với một công cụ như curl thì tôi không muốn bất kỳ tính năng nào trong hai thứ đó được bật mặc định
    • Cũng nên thêm -i, cho phép Wget đọc URL từ một tệp
      Đặc biệt wget -i - đọc từ đầu vào chuẩn nên rất hữu ích trong pipeline
      Theo tôi biết thì curl không làm được việc này. Người ta thường bảo dùng xargs, nhưng như vậy phải đợi đến khi tất cả URL đến rồi mới chạy curl, tức là đánh mất tính song song giữa lệnh sinh URL và lệnh tải xuống, nên không hẳn là một phương án thay thế tốt
    • Cả hai công cụ đều có chỗ dùng riêng. Với sự xuất hiện của mô hình ngôn ngữ lớn như ChatGPT, tôi nghĩ việc lấy được câu thần chú dòng lệnh phù hợp cho bất kỳ công cụ nào đã dễ hơn nhiều
      Dù trước đây đã đọc hướng dẫn, việc nhớ chính xác flag mình muốn cũng không dễ; thường thì kiểm chứng một dòng lệnh được sinh ra sẽ đỡ tốn công hơn là đọc hướng dẫn rồi tự ghép từ đầu
      Trên web hiện đại, đôi khi dùng các công cụ như Puppeteer trong script tự viết còn dễ hơn. Đặc biệt là khi trang bạn tương tác dùng nhiều JavaScript
    • Cá nhân tôi cũng khó chịu vì trình phân tích URL của curl nghiêm ngặt hơn wget rất nhiều
      Ví dụ $ curl -sSLOJ 'example.com/file name.txt' báo lỗi curl: (3) URL using bad/illegal format or missing URL, còn $ curl -sSLOJ 'example.com/file%20name.txt' tạo ra tệp tên file%20name.txt
      Ngược lại, wget tạo tệp "file name.txt" từ cả hai URL mà không cần flag bổ sung. Tuy nhiên URL ví dụ này trả 404, nên nói cho chặt chẽ thì với wget cũng phải thêm --content-on-error
  • Với nhiều người, khác biệt cốt lõi có lẽ là giữa công cụ mặc định ghi ra đầu ra chuẩncông cụ mặc định tạo tệp

    • Hoặc là công cụ mặc định có thể pipe vào sh ;-)
  • Với tôi, tính năng quyết định của Wget là mặc định nó tải tệp xuống với tên tệp suy ra từ URL
    Chạy wget url://to/file.htm thì trong thư mục làm việc hiện tại sẽ có một tệp tên "file.htm"
    Với curl thì phải viết kiểu curl url://to/file.htm > file.htm, hoặc dùng một câu lệnh khác kém tiện hơn

    • curl -O
      https://curl.se/docs/manpage.html#-O
    • Đúng là vậy, nhưng có trường hợp như wget "url://to/file.htm?uid=foo&q=bar&rnd=4"
    • Tôi luôn xem đây là một tính năng sai của Wget. Vì nguyên tắc chung là tiện ích dòng lệnh, nếu không được chỉ thị riêng, nên ghi kết quả chính ra đầu ra chuẩn
    • curl -O tiện hơn
      Nếu ví “tính năng quyết định” đó với cat, thì cat file.html sẽ biến thành cat file.html > file.html. Khi đó nếu thật sự muốn in ra chứ không phải sao chép, bạn sẽ phải dùng kiểu cat file.html -o -, nên tôi mừng là curl không có tính năng như vậy
  • Daniel Stenberg thuộc nhóm hiếm các lập trình viên dốc tâm huyết và linh hồn vào tác phẩm của mình
    Trong Big Tech hiện đại, các lập trình viên như những cái bóng trông như bánh răng thay thế được trong cỗ máy kiếm tiền, và đặc tính như vậy dường như ngày càng biến mất
    Có vẻ ông ấy xem curl như dấu ấn của mình để lại trong thế giới IT

    • Phần mềm tự do có rất nhiều người như vậy. Vì thế tôi dùng phần mềm tự do, dù nó có kém hơn về mặt kỹ thuật
      Tất nhiên ngày nay nhiều khi nó thật sự tốt hơn về mặt kỹ thuật, nên lựa chọn càng dễ hơn
    • Làm việc ở công ty thì có thể bạn không đặt tâm huyết vào sản phẩm của mình, nhưng nếu có một dự án cá nhân phổ biến mang lại rất nhiều tiền mặt, tôi nghĩ ai cũng sẽ tận tâm đến mức đó
  • So sánh này có vẻ hơi cũ. Ví dụ trong biểu đồ, phía Wget thiếu hai thứ dưới đây
    HTTP PUT có thể làm bằng wget --method=PUT --body-data=, còn proxy và HTTPS cũng có thể làm kiểu wget --use-proxy=on --https_proxy=[https://example.com](<https://example.com>;)
    curl nhất quán có nhiều tùy chọn và linh hoạt hơn, nhưng trong số nhiều mục ở phía bên phải của biểu đồ Venn, cũng có những thứ Wget làm được ở một mức nào đó

    • Theo trang man thì có vẻ cũng có hỗ trợ FTP
  • Chà, tôi không biết curl hỗ trợ nhiều giao thức đến vậy. Dù vậy, vùng giao nhau nhỏ kia có lẽ là phần mà hơn 90% người dùng curl/Wget thật sự sử dụng
    Từ góc nhìn nhà phát triển thì phần chồng lấp không lớn lắm, nhưng từ góc nhìn người dùng thì nó có thể trông lớn hơn nhiều

  • Phần tôi thích nhất trong bài là câu này
    “Tôi từng đóng góp mã cho wget. Nhiều maintainer của wget cũng đã đóng góp cho curl. Tất cả chúng tôi đều là bạn.”

  • Bản so sánh do Daniel Stenberg tạo cũng là thứ nhất định phải xem
    https://daniel.haxx.se/docs/curl-vs-wget.html

    • Bản so sánh mới này cũng do Daniel Stenberg tạo và được host trên cùng domain, nhưng nó nằm trên blog của ông ấy chứ không phải tài liệu của curl
  • Ngày xưa khi muốn mirror một website, tôi dùng Wget. Wget là một công cụ chuyên biệt
    curl là một thư viện request đa dụng có CLI frontend, và cũng được nhúng vào các chương trình khác hoặc dùng như API thư viện chuẩn trong PHP, v.v.

    • Cá nhân tôi thích httrack để mirror, nhưng Wget có chức năng chuyển đổi href/src nên đôi khi phù hợp hơn với một số mục tiêu cụ thể
  • Cách dùng phổ biến nhất có lẽ là phần chồng lấp của hai công cụ. Vì vậy tôi muốn thấy một biểu đồ Venn cho biết mỗi công cụ được cài sẵn trên hệ điều hành và Docker image nào