Gereksiz kedileri umursamalı mıyım?

Bir çok komut satırı yardımcı programı girişlerini bir borudan veya dosya adı argümanı olarak alabilir. Uzun kabuk betikleri için cat, özellikle ilk komutun çok satırlı argümanlara gereksinim duyması durumunda, zinciri başlatmayı daha okunaklı hale getirir buluyorum .

Karşılaştırmak

sed s/bla/blaha/ data \
| grep blah \
| grep -n babla

ve

cat data \
| sed s/bla/blaha/ \
| grep blah \
| grep -n babla

İkinci yöntem daha az verimli midir? Eğer öyleyse, betiğin çalıştırılıp çalıştırılmayacağına dikkat etmek için gereken fark, yani saniyede bir kere mi? Okunabilirlik farkı çok büyük değil.

"Kesin" cevabı elbette size Yararsız catÖdül Kullanımı tarafından getirilmiştir .

Kedinin amacı, dosyaları birleştirmek (veya "catenate") yapmaktır. Yalnızca bir dosyaysa, hiçbir şeyle birleştirmek bir zaman kaybıdır ve size bir işlem maliyeti gösterir.

Sadece kodunuzu farklı bir şekilde okumak için cat'ı başlatmak, sadece bir işlem daha gerektirmez ve bir tane daha girdi / çıktı akışı yapar. Genelde senaryolarınızdaki gerçek değer yetersiz döngüler ve gerçek işlemlerdir. Çoğu modern sistemde, bir ekstra catperformansınızı öldürmez, ancak kodunuzu yazmanın hemen hemen her zaman başka bir yolu vardır.

Not ettiğiniz gibi çoğu program giriş dosyası için bir argüman kabul edebilir. Bununla birlikte, <bir STDIN akımının beklendiği yerde kullanılabilecek , her zaman çalışmakta olan kabuk işleminde işi yaparak size bir işlem kazandıracak kabuk yerleşimi her zaman vardır .

Nerede yazdığın ile yaratıcı bile olabilirsin. Normal olarak, böyle bir çıkış yönlendirmesi veya borusu belirtmeden önce komutun sonuna yerleştirilir:

sed s/blah/blaha/ < data | pipe

Ancak bu şekilde olmak zorunda değildir. İlk önce bile gelebilir. Örneğin, örnek kodunuz şöyle yazılabilir:

< data \
    sed s/bla/blaha/ |
    grep blah |
    grep -n babla

Kod okunabilirliği sizin endişeniz ise ve kodunuzun cattakip etmeyi kolaylaştırması için bir satır eklemenin beklendiği kadar karışık olması durumunda, kodunuzu temizlemenin başka yolları da vardır. Daha sonra anlayabilmek için senaryoları kolaylaştıracak bir çok şey kullanıyorum, boruları mantıksal setlere ayırmak ve onları fonksiyonlara kaydetmek. Betik kodu daha sonra doğal hale gelir ve boru hattının herhangi bir bölümünün hata ayıklaması daha kolaydır.

function fix_blahs () {
    sed s/bla/blaha/ |
    grep blah |
    grep -n babla
}

fix_blahs < data

Daha sonra devam edebilirsiniz fix_blahs < data | fix_frogs | reorder | format_for_sql. Böyle okuyan bir boru hattının takip edilmesi gerçekten kolaydır ve her bir bileşen ilgili fonksiyonlarında kolayca hata ayıklanabilir.

İşte bazı dezavantajları bir özeti:

cat $file | cmd

bitmiş

< $file cmd

• Birincisi, bir not: yukarıda kasıtlı olarak (tartışmanın amacına göre) çift tırnak yoktur $file. Bu durumda cat, bunun dışında daima bir problem vardır zsh; yeniden yönlendirme durumunda, bu yalnızca bashveya ksh88yalnızca ve etkileşimli olduğunda diğer komut kabuklarında (komut dosyalarında değil) sorun olur.
• En sık alıntı yapılan dezavantaj, ortaya çıkan ekstra işlemdir. Eğer unutmayın cmdyerleşiğidir bazı kabukları gibi de, o bile 2 süreçler var bash.
• Halen performans cephesinde, catyerleşik kabukları haricinde , ayrıca ekstra bir komut yürütülmekte (ve tabii ki yüklenmekte ve başlatılmaktadır (ve bununla bağlantılı olduğu kütüphaneler)).
• Yine de performans cephesinde, büyük dosyalar için, sistemin dönüşümlü olarak catve cmdsüreçleri programlaması ve boru tamponunu sürekli doldurması ve boşaltması gerektiği anlamına gelir . Bile cmdyapar 1GBgeniş read()sistem anda çağrıları kontrol arasında ileri ve geri gitmek zorunda kalacak catve cmdbir boru bir anda birkaç veri kilobayt fazla tutamayacak çünkü.
• Bazıları cmd(gibi wc -c), stdinleri normal bir dosya olduğu zaman bazı optimizasyonlar yapabilir cat | cmd; stdinleri sadece bir pipo olduğu için yapamadıkları normal bir dosyadır . İle catve bir boru, o da bunu yapamazlar demektir seek()dosya içinde. tacVeya gibi komutlar için tail, bu, performansta büyük bir fark yaratır; bu da cat, bütün girişi bellekte saklamaları gerektiği anlamına gelir .
• cat $fileVe hatta onun daha doğru versiyonu cat -- "$file"gibi bazı özel dosya adları için düzgün çalışmaz -(veya --helpya ile başlayan şey -unutursanız --). Biri kullanmakta ısrar ederse cat, muhtemelen cat < "$file" | cmdgüvenilirlik için kullanması gerekir .
• Eğer $file(erişim engellendi, ... yok) okumak için açık olamaz, < "$file" cmd(kabuk tarafından) tutarlı bir hata mesajı rapor edecek değil koşmak cmdiken, cat $file | cmdhala çalışır cmdancak boş bir dosya gibi onun Stdin seyir ile. Bu da gibi şeyler demektir < file cmd > file2, file2eğer clobbered değildir fileaçılamaz.

<fileBir boru hattının sonuna koymak cat file, başlangıçta olduğundan daha az okunabilir . Doğal İngilizce soldan sağa okur.

<fileDiyelim ki boru hattının başlangıcını koymak kediden daha az okunabilir. Bir sözcük bir sembolden, özellikle yanlış yöne işaret eden bir sembolden daha okunur.

Kullanarak formatı catkorur command | command | command.

Buradaki diğer cevapların doğrudan ele almadığı gibi görünen şeylerden biri cat, böyle bir kullanımın “işe yaramaz bir yabancı kedi sürecinin doğduğu” anlamında “işe yaramaz” olmadığı; “Gereksiz iş yapan kedi sürecinin doğurulması” anlamında faydasızdır.

Bu iki durumda:

sed 's/foo/bar/' somefile
<somefile sed 's/foo/bar/'

Kabuk, bazı dosyalardan veya stdin'den (sırasıyla) okuyan bir sed işlemini başlatır ve sonra bazı işlemleri yapar - yeni bir satıra gelinceye kadar okur, bu satırdaki ilk 'foo' (varsa) 'bar' ile değiştirir, sonra yazdırır. Bu çizgi stdout ve döngülere.

Bu durumuda:

cat somefile | sed 's/foo/bar/'

Kabuk, bir kedi süreci ve sed bir işlem ortaya çıkarır ve kedinin sed's std'üne tel bağlar. Kedi işlemi dosyadan bir kaç kilo veya belki de megabayt yığın okur, daha sonra yukarıdaki ikinci örnekte olduğu gibi oradan alınan bir başkasının aldığı yerden stdout'a yazar. Sed bu odun işlerken, kedi başka bir öbek okuyor ve bir sonraki üzerinde çalışması için stdout'una yazıyor.

Başka bir deyişle, catkomut ekleyerek gereken fazladan iş sadece fazladan bir catişlem üretmek için fazladan bir iş değil , aynı zamanda dosyanın baytlarını bir defada iki kez okumak ve yazmaktan başka bir şey değildir. Şimdi, pratik olarak konuşursak ve modern sistemlerde, bu büyük bir fark yaratmıyor - sisteminizi gereksiz yere birkaç mikrosaniye yapar. Ancak, dağıtmayı planladığınız bir senaryo için, potansiyel olarak zaten gücü çok düşük olan makinelerde kullanan insanlar için, birkaç mikrosaniye birçok yinelemenin üzerine ekleyebilir.