curl-wget Venn diyagramı

 (daniel.haxx.se)
2 puan yazan GN⁺ 2023-09-05 | 1 yorum | WhatsApp'ta paylaş
  • wget, curl’ün doğrudan rakibi değil; işe göre birlikte de kullanılabilen, işlevleri kısmen örtüşen bir araç olarak görülmeli
  • Seçim ölçütü araç tercihi değil, işi tamamlamaya daha uygun olup olmadığı; wget daha uygunsa wget kullanılmalı
  • curl ile wget arasındaki teknik farklar ve örtüşen alanlar, bir bakışta görülebilmesi için Venn diyagramı ile düzenlenmiş; ayrıca tam çözünürlüklü görsel de sunuluyor
  • İki proje karşı karşıya değil; curl tarafı wget’e kod katkısında bulundu ve birçok wget bakımcısı da curl’e katkı yaptı
  • Diyagramdaki hatalar ya da eksikler güncellenebilir; ayrıca ayrı bir karşılaştırma belgesi ve indirme araçları karşılaştırma tablosundan daha ayrıntılı bilgi alınabilir

curl ve wget’e bakış ölçütü

  • wget, curl’ün rakibinden çok tamamlayıcı bir araça yakın
  • İki araç bazı işlevlerde örtüşse de asıl mesele, belirli bir aracı dayatmak değil, çözülmek istenen işe uygun seçimi yapmak
  • Herhangi bir durumda wget işi tamamlamak için daha uygunsa wget kullanmak daha iyi olur

Venn diyagramıyla özetlenen farklar

  • curl ile wget arasındaki teknik farkları ve bazı benzerlikleri görsel olarak göstermek için bir Venn diyagramı hazırlanmış
  • Diyagram görseline tıklayınca tam çözünürlüklü sürüm görülebiliyor
  • Sorun ya da eksik maddeler bulunursa bildirilmesi isteniyor; gerekirse diyagram güncellenebiliyor

Projeler arası işbirliği

  • curl tarafı daha önce wget’e kod katkısında bulundu
  • Birçok wget bakımcısı da daha önce curl’e katkı yaptı
  • İki proje arasındaki ilişki rekabetten ya da karşıtlıktan çok işbirliğine yakın

İncelenebilecek diğer karşılaştırma kaynakları

İlgili okumalar

1 yorum

 
GN⁺ 2023-09-05
Hacker News yorumları

  • Wget tarafına en azından makul varsayılanlar, devam ettirme ve hata durumunda yeniden denemeyi de koymak gerektiğini düşünüyorum.
    Yakın zamanda kararsız bir bağlantı üzerinden çok büyük bir dosya indiren bir betik yazmam gerekti; mühendisler arasındaki genel kanaat, bu tür işler için Wget kullanmak gerektiğiydi.
    curl’ü de denedim ama varsayılan hâliyle devam ettirme ya da yeniden deneme yapmıyordu; kılavuzu okuyup çeşitli seçenekler ve argümanlar belirtmem gerekti. Bu davranışların varsayılan olması gerektiğini hissettim.
    Wget’te çökmeden sonrası da dahil her durumda devam ettirmeyi açmak için tek bir --continue seçeneği yetti; kılavuzun girişinde de yavaş ya da kararsız ağlarda sağlam çalışacak şekilde tasarlandığı, indirme başarısız olursa dosyanın tamamı alınana kadar yeniden denemeye devam ettiği yazıyor.
    curl ile de kötü bağlantılarda güvenilir çalışması için tüm seçenekler ayarlanabilir, ama Wget’te bu varsayılan davranış zaten açıkmış gibi geldiği için bizzat test edemediğim hata durumlarında da beklediğim gibi davranacağına güveniyorum. HTTP protokolü güncellense bile yeni Wget’in bunu varsayılan olarak destekleme ihtimali var; curl’de ise iyileştirilmiş davranışı açmak için yeni bir anahtar gerekebilir ve ürün yayımlandıktan sonra bunu ekleyemeyebilirsiniz.
    Benim için curl harika ve çok yönlü bir düşük seviyeli araç; CLI’ı da bu karakteri yansıtıyor. Ama günlük işlerde Wget varsayılan hâliyle çok daha iyi çalıştığı için onu tercih ediyorum. Kılavuzuna da daha hızlı göz atılabiliyor; muhtemelen burada bahsedilen tüm o anlaşılması güç protokolleri desteklemediği içindir.

    • Makul varsayılanlar kısmına katılıyorum.
      Sırf wget url ile URL’yi indirip kaydetmesi bile komut satırı kullanımında Wget’i öne geçiriyor bence.
    • curlde de tam olarak bu özellik var. Devam ettirme -C bayrağıyla, yeniden deneme de --retry ile yapılıyor.
      Kişisel olarak curl’ün varsayılanlarını da oldukça makul buluyorum; curl gibi bir araçta bu ikisinden herhangi birinin varsayılan olarak açık olmasını istemem.
    • Wget’in bir dosyadan URL okumasını sağlayan -i de eklenmeli.
      Özellikle wget -i -, standart girdiden okuduğu için boru hatlarında çok kullanışlı.
      Bildiğim kadarıyla curl bunu yapamıyor. Genellikle xargs kullanın deniyor ama tüm URL’ler gelene kadar bekleyip sonra curl’ü çalıştırdığı için URL üreten komut ile indirme komutu arasındaki paralelliği feda ediyorsunuz; bu yüzden muadil olarak biraz belirsiz kalıyor.
    • İki aracın da kendi kullanım alanı var. ChatGPT gibi büyük dil modelleri ortaya çıktığından beri, hangi aracı kullanırsanız kullanın uygun komut satırı “büyüsünü” elde etmek çok daha kolaylaştı bence.
      Daha önce kılavuzu okumuş olsanız bile istediğiniz bayrağı tam olarak hatırlamak kolay değil; üretilen komut satırını doğrulamak, genelde kılavuzu okuyup sıfırdan bir araya getirmekten daha az zahmetli oluyor.
      Modern web’de, kendi yazdığınız betiklerde Puppeteer gibi araçlar kullanmak bazen daha kolay olabiliyor. Etkileşim kurduğunuz site JavaScript’i yoğun kullanıyorsa bu özellikle doğru.
    • curl’ün URL ayrıştırıcısının wget’ten çok daha katı olması da kişisel olarak canımı sıkan bir nokta.
      Örneğin $ curl -sSLOJ 'example.com/file name.txt', curl: (3) URL using bad/illegal format or missing URL hatası veriyor; $ curl -sSLOJ 'example.com/file%20name.txt' ise file%20name.txt adlı bir dosya oluşturuyor.
      Buna karşılık wget, ek bayrak olmadan iki URL’den de "file name.txt" adlı dosyayı oluşturuyor. Ancak bu örnek URL 404 döndürdüğü için, kesin konuşmak gerekirse wget’e --content-on-error da eklemek gerekir.

  • Birçok kişi için temel fark muhtemelen varsayılan olarak standart çıktıya yazan araç ile varsayılan olarak dosya oluşturan araç arasındadır.

    • Ya da varsayılan olarak sh’e pipe edilebilen araç ;-)

  • Benim için Wget’in belirleyici özelliği, dosyayı varsayılan olarak URL’den türetilen dosya adıyla indirmesi.
    wget url://to/file.htm çalıştırdığınızda mevcut çalışma dizininde "file.htm" adlı bir dosya oluşuyor.
    curl ile curl url://to/file.htm > file.htm gibi yazmanız ya da bundan daha az pratik başka bir komut kullanmanız gerekiyor.

    • curl -O
      https://curl.se/docs/manpage.html#-O
    • Doğru ama wget "url://to/file.htm?uid=foo&q=bar&rnd=4" gibi durumlar var.
    • Ben bunu hep Wget’in hatalı bir özelliği olarak gördüm. Çünkü komut satırı yardımcı programlarının, aksi özellikle belirtilmediği sürece ana sonucunu standart çıktıya yazması gerektiği yönünde genel bir ilke var.
    • curl -O daha kullanışlı.
      O “belirleyici özelliği” cate benzetirsek, cat file.html komutunun cat file.html > file.htmle dönüşmesi gibi olur. O zaman gerçekten kopyalamak değil de çıktı almak istediğinizde cat file.html -o - gibi bir şey yazmanız gerekir; bu yüzden curl’de böyle bir özellik olmadığı için memnunum.

  • Daniel Stenberg, kendi eserine kalbini ve ruhunu koyan nadir geliştirici türlerinden.
    Modern büyük teknoloji şirketlerinde geliştiriciler, para basma makinesinin değiştirilebilir dişlileri gibi gölge figürler olarak görünüyor; bu özellik giderek kayboluyor sanki.
    O, curl’ü IT dünyasında bıraktığı kendi izi gibi ele alıyor gibi görünüyor.

    • Özgür yazılım böyle insanlarla dolu. Bu yüzden teknik olarak daha zayıf olsa bile özgür yazılım kullanıyorum.
      Elbette bugünlerde gerçekten teknik olarak daha iyi olduğu birçok durum da var, bu da seçimi kolaylaştırıyor.
    • Bir şirkette çalışıyorsanız kendi eseriniz için bu kadar emek vermeyebilirsiniz; ama size bol nakit kazandıran popüler bir kişisel projeniz varsa herkesin bu kadar adanmış olacağını düşünüyorum.

  • Bu karşılaştırma biraz eskimiş gibi. Örneğin diyagramda Wget tarafında şu ikisi eksik:
    HTTP PUT, wget --method=PUT --body-data= ile mümkün; proxy ve HTTPS de wget --use-proxy=on --https_proxy=[https://example.com](<https://example.com>;) gibi kullanılabiliyor.
    curl tutarlı biçimde daha fazla seçeneğe ve esnekliğe sahip, ancak Venn diyagramının sağ tarafındaki birçok öğeden bazılarını Wget de bir ölçüde yapabiliyor.

    • Kılavuz sayfasına göre FTP desteği de var gibi görünüyor.

  • Vay, curl’ün bu kadar çok protokol desteklediğini bilmiyordum. Yine de küçük kesişim bölgesi muhtemelen curl/Wget kullanıcılarının %90’ından fazlasının fiilen kullandığı kısım.
    Geliştirici açısından bakınca örtüşen alan çok büyük değil, ama kullanıcı açısından çok daha büyük görünebilir.

  • Yazıda en sevdiğim bölüm şu cümleydi:
    “wget’e kod katkısında bulundum. Birkaç wget bakımcısı da curl’e katkıda bulundu. Hepimiz arkadaşız.”

  • Daniel Stenberg’in yaptığı karşılaştırma da mutlaka görülmeli:
    https://daniel.haxx.se/docs/curl-vs-wget.html

    • Bu yeni karşılaştırma da Daniel Stenberg tarafından yapılmış ve aynı alan adında barındırılıyor; ancak curl belgelerinde değil, onun blogunda yer alıyor.

  • Eskiden bir web sitesini yansılamak istediğimde Wget kullanırdım. Wget uzmanlaşmış bir araç.
    curl ise CLI ön yüzü olan genel amaçlı bir istek kütüphanesi; başka programlara gömülebiliyor ya da PHP gibi dillerin standart kütüphane API’si gibi kullanılabiliyor.

    • Kişisel olarak yansılama için httrack’i seviyorum, ama Wget’te href/src dönüştürme özelliği olduğu için belirli hedeflerde bazen daha uygun olabiliyor.

  • En yaygın kullanımın ikisinin kesişen kısmı olduğunu sanıyorum. Bu yüzden her aracın hangi işletim sistemi ve Docker imajında varsayılan olarak kurulu olduğunu gösteren bir Venn diyagramı görmek isterdim.