Apa konsensus umum tentang “Penggunaan kucing yang tidak berguna”?

Ketika saya mem-pipe beberapa perintah unix seperti grep, sed, tr dll. Saya cenderung menentukan file input yang sedang diproses menggunakan cat. Jadi sesuatu seperti itu cat file | grep ... | awk ... | sed ....

Tetapi baru-baru ini setelah beberapa komentar meninggalkan jawaban saya yang menunjukkan bahwa ini adalah penggunaan kucing yang tidak berguna, saya pikir saya akan mengajukan pertanyaan di sini.

Saya melihat masalah ini dan menemukan artikel Wikipedia tentang UUOC dan Penggunaan yang Tidak Berguna dari Penghargaan Kucing dan bagi saya tampaknya argumen yang dibuat berasal dari perspektif efisiensi.

Pertanyaan terdekat yang saya temui di sini adalah pertanyaan ini: Apakah boros memanggil kucing? - tapi itu tidak cukup apa yang saya minta.

Saya kira apa yang disarankan oleh UUOC untuk digunakan cmd1 args < file | cmd2 args | cmd3 ..atau jika perintah memiliki opsi untuk membaca dari file kemudian meneruskannya sebagai argumen.

Tetapi bagi saya cat file | cmd1 ... | cmd2tampaknya lebih mudah dibaca dan dipahami. Saya tidak harus mengingat berbagai cara mengirim file input ke perintah yang berbeda, dan proses mengalir secara logis dari kiri ke kanan. Input pertama, lalu proses pertama ... dan seterusnya.

Apakah saya gagal memahami argumen apa yang dibuat tentang penggunaan kucing yang tidak berguna? Saya mengerti bahwa jika saya menjalankan pekerjaan cron yang berjalan setiap 2 detik yang melakukan banyak pemrosesan, maka dalam kasus itu kucing mungkin akan sia-sia. Tetapi sebaliknya apa konsensus umum tentang penggunaan kucing?

Ini tidak berguna dalam arti bahwa menggunakannya seperti itu tidak mencapai apa pun yang lain, mungkin opsi yang lebih efisien tidak dapat (yaitu menghasilkan hasil yang tepat).

Tetapi catjauh lebih kuat dari sekedar cat somefile. Konsultasikan man catatau baca apa yang saya tulis dalam jawaban ini . Tetapi jika Anda benar-benar hanya perlu isi dari satu file, Anda mungkin mendapatkan keuntungan kinerja karena tidak menggunakan catuntuk mendapatkan isi file.

Mengenai keterbacaan, ini tergantung pada selera pribadi Anda. Saya suka catmemasukkan file ke perintah lain untuk alasan yang sama, terutama jika aspek kinerja dapat diabaikan.

Itu juga tergantung pada apa yang Anda skrip. Jika itu adalah shell Anda sendiri dan metode kenyamanan untuk mesin desktop Anda, tidak seorang pun kecuali Anda akan peduli. Jika Anda menemukan suatu kasus di mana alat berikutnya dalam rantai akan lebih baik untuk dapat mencari, dan mendistribusikannya sebagai perangkat lunak yang sering digunakan pada beberapa sistem Linux minimal pada router berkinerja rendah atau perangkat serupa dengan batas nyata pada kemampuan pemrosesan, itu berbeda. Itu selalu tergantung pada konteksnya.

Dalam setiap hari penggunaan command line tidak jauh berbeda. Anda terutama tidak akan melihat perbedaan kecepatan karena waktu pada CPU dihindari dengan tidak menggunakan cat, CPU Anda hanya akan menganggur. Sekalipun Anda melakukan perulangan melalui ratusan atau ribuan (atau bahkan ratusan ribu) item dalam semua kepraktisannya, itu tidak akan membuat banyak perbedaan, kecuali jika Anda menggunakan sistem yang sangat dimuat (Load Average / N CPU> 1).

Di mana karet bertemu jalan adalah tentang membentuk kebiasaan baik dan mencegah yang buruk. Untuk menyeret keluar klise berjamur, iblis ada di detailnya. Dan detail seperti ini yang memisahkan yang biasa-biasa saja dari yang hebat.

Ini seperti saat mengendarai mobil, mengapa belok kiri ketika Anda bisa membuat tiga hak saja? Tentu saja Anda bisa, dan itu bekerja dengan sempurna. Tetapi jika Anda memahami kekuatan belokan kiri maka tiga hak tampaknya konyol.

Ini bukan tentang menyimpan satu pegangan file, 17k RAM dan 0,004 detik waktu CPU. Ini tentang seluruh filosofi menggunakan UNIX. "Kekuatan belokan kiri" dalam ilustrasi saya tidak hanya mengarahkan input, itu adalah filosofi UNIX. Sepenuhnya mengoceh ini akan membuat Anda unggul jauh lebih baik daripada orang-orang di sekitar Anda, dan Anda akan mendapatkan rasa hormat dari mereka yang mengerti.

Saya sering menggunakan cat file | myprogramcontoh. Terkadang saya dituduh menggunakan kucing yang tidak berguna ( http://www.iki.fi/era/unix/award.html ). Saya tidak setuju karena alasan berikut:

Sangat mudah untuk memahami apa yang sedang terjadi.

Saat membaca perintah UNIX Anda mengharapkan perintah diikuti oleh argumen yang diikuti oleh pengalihan. Hal ini memungkinkan untuk menempatkan di mana saja redirection tetapi jarang terlihat - dengan demikian orang akan memiliki waktu yang sulit membaca contoh. aku percaya

    cat foo | program1 -o option -b option | program2

lebih mudah dibaca daripada

    program1 -o option -b option < foo | program2

Jika Anda memindahkan pengalihan ke awal, Anda membingungkan orang-orang yang tidak terbiasa dengan sintaks ini:

    < foo program1 -o option -b option | program2

dan contoh harus mudah dipahami.

Mudah diubah.

Jika Anda tahu program dapat membaca dari cat, Anda biasanya dapat menganggapnya dapat membaca output dari program apa pun yang menghasilkan STDOUT, dan dengan demikian Anda dapat menyesuaikannya untuk kebutuhan Anda sendiri dan mendapatkan hasil yang dapat diprediksi.

Ini menekankan bahwa program tidak gagal, jika STDIN bukan file biasa.

Tidak aman untuk mengasumsikan bahwa jika program1 < fooberhasil maka cat foo | program1juga akan berhasil. Namun, adalah dalam praktek aman untuk mengasumsikan sebaliknya. Program ini berfungsi jika STDIN adalah file, tetapi gagal jika inputnya berupa pipa, karena menggunakan seek:

    # works
    < foo perl -e 'seek(STDIN,1,1) || die;print <STDIN>'

    # fails
    cat foo | perl -e 'seek(STDIN,1,1) || die;print <STDIN>'

Saya telah melihat penalti kinerja pada http://oletange.blogspot.dk/2013/10/useless-use-of-cat.html Kesimpulannya adalah jangan gunakan cat file |jika kompleksitas pemrosesan mirip dengan grep sederhana dan kinerja lebih penting daripada keterbacaan. Untuk situasi lain cat file |baik-baik saja.

Saya pikir posisi yang diambil oleh beberapa dari mereka yang mengomentari sesuatu menjadi UUOC adalah bahwa jika seseorang benar-benar memahami Unix dan shell sintaks, seseorang tidak akan menggunakan cat dalam konteks itu. Ini terlihat seperti menggunakan tata bahasa yang buruk: Saya bisa menulis kalimat menggunakan tata bahasa yang buruk dan masih bisa menyampaikan maksud saya, tetapi saya juga menunjukkan pemahaman saya yang buruk tentang bahasa dan dengan perluasan, pendidikan saya yang buruk. Jadi mengatakan bahwa sesuatu adalah UUOC adalah cara lain untuk mengatakan seseorang tidak mengerti apa yang mereka lakukan.

Sejauh efisiensi berjalan, jika Anda mengeksekusi pipa dari baris perintah, dibutuhkan waktu lebih sedikit bagi mesin untuk mengeksekusi cat somefile |daripada bagi Anda untuk memikirkan apakah mungkin lebih efisien untuk digunakan < somefile. Itu tidak masalah.

Saya tidak mengetahui penghargaan itu sampai hari ini ketika beberapa pemula mencoba untuk menempelkan UUOC pada saya untuk salah satu jawaban saya. Itu adalah cat file.txt | grep foo | cut ... | cut .... Saya memberinya sedikit pikiran, dan hanya setelah itu mengunjungi tautan dia memberi saya merujuk pada asal-usul penghargaan dan praktik melakukannya. Pencarian lebih lanjut membawa saya ke pertanyaan ini. Sayangnya, meski dengan pertimbangan sadar, tidak ada jawaban yang termasuk alasan saya.

Saya tidak bermaksud bersikap defensif ketika mendidiknya. Setelah semua, di tahun-tahun muda saya, saya akan menulis perintah karena grep foo file.txt | cut ... | cut ...karena setiap kali Anda melakukan single grepAnda belajar penempatan argumen file dan siap pengetahuan bahwa yang pertama adalah pola dan yang kemudian adalah nama file.

Itu adalah pilihan sadar ketika saya menjawab pertanyaan dengan catawalan sebagian karena alasan "selera yang baik" (dalam kata-kata Linus Torvalds) tetapi terutama karena alasan fungsi yang meyakinkan.

Alasan terakhir lebih penting sehingga saya akan memadamkannya terlebih dahulu. Ketika saya menawarkan pipa sebagai solusi saya berharap itu dapat digunakan kembali. Sangat mungkin bahwa pipa akan ditambahkan pada akhir atau disambungkan ke pipa lain. Dalam hal ini memiliki argumen file untuk menangkap kembali usabilitas, dan sangat mungkin melakukannya diam - diam tanpa pesan kesalahan jika argumen file ada. Saya. E. grep foo xyz | grep bar xyz | wcakan memberi Anda berapa banyak baris dalam xyzberisi barsaat Anda mengharapkan jumlah baris yang mengandung keduanya foodan bar. Harus mengubah argumen ke perintah dalam pipa sebelum menggunakannya cenderung mengalami kesalahan. Tambahkan ke dalamnya kemungkinan kegagalan diam dan itu menjadi praktik yang sangat berbahaya.

Alasan sebelumnya juga tidak penting karena banyak "selera yang baik" semata-mata adalah alasan bawah sadar yang intuitif untuk hal-hal seperti kegagalan diam di atas yang tidak dapat Anda pikirkan tepat pada saat ketika seseorang yang membutuhkan pendidikan mengatakan "tetapi tidak kucing itu tidak berguna ".

Namun, saya akan mencoba juga membuat sadar alasan "selera baik" yang saya sebutkan sebelumnya. Alasan itu berkaitan dengan semangat desain ortogonal Unix. greptidak cutdan lstidak grep. Karena itu paling grep foo file1 file2 file3tidak bertentangan dengan semangat desain. Cara ortogonal untuk melakukannya adalah cat file1 file2 file3 | grep foo. Sekarang, grep foo file1ini hanyalah kasus khusus grep foo file1 file2 file3, dan jika Anda tidak memperlakukannya sama, Anda setidaknya menggunakan siklus jam otak untuk menghindari penghargaan kucing yang tidak berguna.

Itu membawa kita ke argumen yang grep foo file1 file2 file3menyatukan, dan catmenyatukan jadi itu pantas untuk cat file1 file2 file3tetapi karena cattidak menyatukan dalam cat file1 | grep fookarena itu kita melanggar semangat baik catUnix dan Mahakuasa. Nah, jika itu yang terjadi maka Unix akan membutuhkan perintah yang berbeda untuk membaca output dari satu file dan meludahkannya ke stdout (bukan paginate atau apa pun hanya meludah murni untuk stdout). Jadi Anda akan memiliki situasi di mana Anda mengatakan cat file1 file2atau Anda katakan dog file1dan dengan sadar ingat untuk menghindari cat file1untuk menghindari mendapatkan penghargaan, sementara juga menghindari dog file1 file2karena semoga desain dogakan melempar kesalahan jika beberapa file ditentukan.

Mudah-mudahan pada titik ini Anda bersimpati dengan desainer Unix untuk tidak memasukkan perintah terpisah untuk meludah file ke stdout, sementara juga penamaan catuntuk concatenate daripada memberinya beberapa nama lain. <edit>ada anjing seperti itu, <operator yang malang . Sangat disayangkan penempatannya di ujung pipa mencegah kompabilitas yang mudah. Tidak ada cara yang bersih secara sintaksis atau estetis untuk menempatkannya di awal. Sangat disayangkan tidak cukup umum sehingga Anda mulai dengan anjing tetapi cukup tambahkan nama file lain jika Anda juga ingin diproses setelah yang sebelumnya. (Di >sisi lain tidak setengah buruk. Ini memiliki penempatan yang hampir sempurna pada akhirnya. Biasanya bukan bagian yang dapat digunakan kembali dari pipa, dan karenanya dibedakan secara simbolis.)</edit>

Pertanyaan selanjutnya adalah mengapa penting untuk memiliki perintah yang hanya meludah file atau gabungan beberapa file untuk stdout, tanpa proses lebih lanjut? Salah satu alasannya adalah untuk menghindari setiap perintah Unix tunggal yang beroperasi pada input standar untuk mengetahui cara mengurai setidaknya satu argumen file baris perintah dan menggunakannya sebagai input jika ada. Alasan kedua adalah untuk menghindari pengguna harus mengingat: (a) ke mana argumen nama file pergi; dan (b) menghindari bug pipa diam seperti yang disebutkan di atas.

Itu membawa kita ke mengapa grepmemang memiliki logika ekstra. Alasannya adalah untuk memungkinkan pengguna-kelancaran untuk perintah yang sering digunakan dan atas dasar yang berdiri sendiri (bukan sebagai saluran pipa). Ini adalah sedikit kompromi ortogonalitas untuk keuntungan yang signifikan dalam kegunaan. Tidak semua perintah harus dirancang dengan cara ini dan perintah yang tidak sering digunakan harus sepenuhnya menghindari logika ekstra argumen file (ingat logika tambahan mengarah pada kerapuhan yang tidak perlu (kemungkinan bug)). Pengecualian adalah untuk memungkinkan argumen file seperti dalam kasus grep. (Omong-omong, catatan yang lsmemiliki alasan yang sangat berbeda untuk tidak hanya menerima tetapi cukup banyak membutuhkan argumen file)

Akhirnya, apa yang bisa dilakukan dengan lebih baik adalah jika perintah yang luar biasa seperti grep(tetapi tidak harus ls) menghasilkan kesalahan jika input standar tersedia. Ini masuk akal karena perintah termasuk logika yang melanggar semangat ortogonal Unix yang maha kuasa untuk kenyamanan pengguna. Untuk kenyamanan pengguna lebih lanjut, yaitu untuk mencegah penderitaan yang disebabkan oleh kegagalan diam, perintah tersebut tidak boleh ragu untuk melanggar pelanggaran mereka sendiri dengan memperingatkan pengguna jika ada kemungkinan kegagalan diam.

Untuk mempertahankan Penggunaan yang Tidak Berguna dari Kucing

(Beberapa paragraf untuk membantu menyeimbangkan tsunami dari komentar yang mengganggu terhadap praktik ini)

Saya telah menggunakan bash selama bertahun-tahun baik sebagai shell dan sebagai bahasa scripting untuk skrip kecil (dan kadang-kadang menyesal untuk yang tidak begitu kecil). Dahulu kala saya telah belajar tentang "Penggunaan Cat yang Tidak Berguna" (UUoC). Saya masih bersalah setidaknya setiap minggu tetapi terus terang saya jarang merasa sedikit dipaksa untuk menghindarinya. Saya percaya bahwa menggunakan catvs < filelebih tentang rasa daripada perbedaan teknis dan saya menulis jawaban ini untuk melindungi orang-orang yang baru mengenal Linuxcatdari berpikir bahwa ada sesuatu yang salah dengan cara mereka (dan perhatikan beberapa kesempatan di mana ada). Seperti Linus Torvalds, saya juga percaya bahwa rasa seringkali lebih penting daripada keterampilan. Itu tidak berarti bahwa seleraku lebih baik daripada seleramu, tetapi itu berarti bahwa jika sesuatu terasa tidak enak aku tidak akan melakukannya tanpa mendapatkan sesuatu yang layak.

Sudah jelas bahwa seperti penulis pertanyaan, saya merasa menggunakan kucing sangat alami ketika mengerjakan REPL seperti bash di mana saya menjelajahi masalah dengan secara bertahap membangun perintah yang rumit. Berikut adalah contoh yang sangat khas: Saya punya file teks dan tidak tahu banyak tentangnya. Saya akan mengetik cat fileuntuk mendapatkan rasa dari isinya. Jika hasilnya terlalu banyak saya akan menekan panah atas saya dan tergantung pada keadaan saya akan menambah | headatau | grep fooatau | what_evermemperpanjang perintah saya sebelumnya dengan menambahkan langkah-langkah pemrosesan. Cara ini secara bertahap beralih dari perintah sederhana ke perintah yang lebih kompleks dengan menambahkan satu langkah pemrosesan setelah yang lainnya terasa sangat alami bagi saya (saya melakukan hal yang sama pada ipython dan saya suka caranyapyfunctionaldan alat pemrograman serupa meliputi gaya ini). Jadi, ketika bekerja pada bash shell saya 'm yakin bahwa mengganggu aliran saya untuk menghapus catadalah lebih berguna daripada membiarkan itu dan menderita ... baik ada konsekuensi sama sekali dalam 99,9% kasus.

Tentu saja ketika menulis skrip, berbagai hal mungkin berubah. Tetapi bahkan ketika menulis skrip, pendapat saya bahwa orang yang mengejek UUoC mengabaikan pelajaran penting ini dengan pikiran yang bagus: "Optimalisasi prematur adalah akar dari semua kejahatan" . Dan jika Anda tidak melakukan sesuatu yang tidak lazim maka sangat sulit untuk UUoC menjadi tempat di mana optimasi akan diperlukan. Tentu saja Anda pasti perlu tahu apa yang tidak efisien tentang hal itu (ini adalah proses doa tambahan BTW karena sedikit yang menyebutkannya). Memiliki pengetahuan itu jika Anda bekerja pada sistem yang langka di mana menjalankan suatu proses itu mahal (misalnya beberapa sistem tertanam atau CygWin ke tingkat yang lebih rendah), Anda akan tahu apa yang harus dilakukan jika situasi khusus mengharuskannya. Misalnya jika Anda menemukan diri Anda meneleponcatberkali-kali dalam satu lingkaran (BTW jika Anda menemukan diri Anda dalam posisi itu bertanya pada diri sendiri apakah bash adalah alat yang tepat untuk pekerjaan itu). Namun sekali lagi: "pertama membuatnya bekerja dengan benar kemudian mengoptimalkannya jika perlu" .

Dan bagaimana Anda menjelaskan tsunami keluhan tentang UUoC Nick?

Selain tidak semua orang memiliki selera saya, saya percaya bahwa sebagian besar alasan mengapa begitu banyak orang mengeluh tentang UUoC bukan teknis tetapi manusia: Kebanyakan pendatang baru Unix tidak akan tahu tentang < file commandidiom itu sehingga menggoda orang yang lebih berpengalaman untuk memainkan "Guru Tua " untuk mereka. Dia juga akan memiliki kesempatan untuk menggunakan kata-kata indah ("proses doa") dan menyentuh subjek "optimasi". Kesan yang baik dijamin sehingga sangat sulit untuk ditolak. Kemudian para pendatang baru akan menerima nasihat dari Guru pada nilai nominal dan untuk waktu yang lama akan memutar ulang kepada orang lain sebagai "The Only Truth" (dan pilih suara ini jawaban :-). Catatan lucu: mungkin sangat mudah untuk memperbaiki bash untuk menghindari ketidakefisienan UUoC sehingga kita harus bertanya-tanya mengapa tidak ada yang menambahkan fitur ini atau membuat< filenamecat file setelah bertahun-tahun. Jiwa yang gelap akan menyarankan bahwa beberapa peretas bash graybeard suka meninggalkan peluang untuk mengejek kita ;-)

Apa yang akan sangat bagus adalah shell yang mendukung sintaksis seperti:

< filename cmd | cmd2 cmd2arg1... | cmd3

Sementara itu, saya pikir cat filename | realcmd1...ini dapat diterima, karena itu membuat sintaks standar dengan perintah awal yang memerlukan nama file sebagai argumen.

Untuk semua yang mengatakan kucing dapat diterima untuk digunakan karena "baunya" lebih baik atau "lebih mudah dibaca" Saya hanya akan mengatakan ini:

Untuk Anda mungkin ... tetapi tidak untuk orang lain yang mungkin membaca atau mencoba memahami kode Anda. Jika Anda tidak akan pernah mencoba menginstruksikan orang lain dengan contoh Anda atau membagikan kode Anda, maka silakan gunakan di waktu luang Anda sendiri.

Saya juga akan menambahkan komentar ini, sebagai pengguna Linux yang lama dan Admin / Engineer ... (dan ada banyak dari kita) itu membuat mata kita berdarah melihat ini. Mengapa? Karena menggunakan sumber daya pada sistem yang kita kontrol sumber daya erat. Perintah cat dan pipa itu sendiri menggunakan memori ekstra dan pegangan file yang sama sekali tidak berguna. Anda telah mengikat sumber daya yang dibutuhkan sistem saya gratis dan Anda telah memperoleh TIDAK ADA yang dapat menjelaskan penggunaan sumber daya ini. Ini sangat besar, tidak, tidak.

Sekarang saya bisa duduk di sini dan berdebat hal-hal seperti bau kode atau keterbacaan sepanjang hari dengan siapa pun, tetapi pada akhirnya itu adalah masalah menulis atau salah dan setiap kali Anda menggunakan sumber daya pada sistem dan tidak mendapatkan apa-apa untuk itu ... ini salah.

Sebagai pengguna rumahan, Anda dapat belajar dari saran saya dan mempelajari cara-cara yang lebih baik untuk melakukan sesuatu atau Anda dapat memilih untuk dibutakan oleh "bau" kucing, pilihan Anda ... tetapi tahu bahwa jika Anda secara terbuka menggunakan praktik ini, Anda akan dipanggil pada latihan ini sepanjang waktu dan Anda harus diam-diam mengakui mereka benar dan Anda keras kepala karena itu benar. :-)