skrip satu baris vs

Saya telah memperhatikan banyak pertanyaan dan jawaban serta komentar yang mengungkapkan penghinaan karena (dan terkadang bahkan takut) menulis skrip alih-alih satu kalimat. Jadi, saya ingin tahu:

• Kapan dan mengapa saya harus menulis skrip yang berdiri sendiri daripada "satu baris"? Atau sebaliknya?

• Apa kasus penggunaan dan pro & kontra dari keduanya?

• Apakah beberapa bahasa (mis. Awk atau perl) lebih cocok untuk one-liners daripada yang lain (misalnya python)? Jika demikian, mengapa?

• Apakah ini hanya masalah preferensi pribadi atau adakah alasan yang baik (yaitu objektif) untuk menulis satu atau yang lain dalam keadaan tertentu? Apa alasannya?

Definisi

• one-liner: setiap urutan perintah yang diketik atau ditempelkan langsung ke baris perintah shell . Sering melibatkan pipa dan / atau penggunaan bahasa seperti sed, awk, perl, dan / atau alat-alat seperti grepatau cutatau sort.

  Eksekusi langsung pada command-line adalah karakteristik yang menentukan - panjang dan format tidak relevan. "One-liner" mungkin semuanya dalam satu baris, atau mungkin memiliki beberapa baris (misalnya sh untuk loop, atau kode awk atau sed yang tertanam, dengan umpan baris dan lekukan untuk meningkatkan keterbacaan).

• script: urutan perintah apa pun dalam bahasa yang ditafsirkan yang disimpan ke dalam file , dan kemudian dieksekusi. Sebuah skrip dapat ditulis seluruhnya dalam satu bahasa, atau skrip shell-wrapper di sekitar beberapa "satu-liners" menggunakan bahasa lain.

Saya punya jawaban sendiri (yang akan saya posting nanti), tetapi saya ingin ini menjadi tanya jawab kanonik pada subjek, bukan hanya pendapat pribadi saya.

Respons lain berdasarkan pengalaman praktis.

Saya akan menggunakan one-liner jika kode "buang" yang bisa saya tulis langsung pada prompt. Sebagai contoh, saya mungkin menggunakan ini:

for h in host1 host2 host3; do printf "%s\t%s\n" "$h" "$(ssh "$h" uptime)"; done

Saya akan menggunakan skrip jika saya memutuskan bahwa kode itu layak disimpan. Pada titik ini saya akan menambahkan deskripsi di bagian atas file, mungkin menambahkan beberapa pengecekan kesalahan, dan bahkan mungkin memeriksanya ke dalam repositori kode untuk versi. Sebagai contoh, jika saya memutuskan bahwa mengecek uptime dari satu set server adalah fungsi yang berguna yang akan saya gunakan lagi dan lagi, one-liner di atas mungkin diperluas ke ini:

#!/bin/bash
# Check the uptime for each of the known set of hosts
########################################################################
#
hosts=(host1 host2 host3)

for h in "${hosts[@]}"
do
    printf "%s\t" "$h"
    uptime=$(ssh -o ConnectTimeout=5 -n "$h" uptime 2>/dev/null)
    printf "%s\n" "${uptime:-(unreachable)}"
done

Generalisasi, bisa dikatakan

• Satu garis

  • Kode sederhana (yaitu hanya "beberapa" pernyataan), ditulis untuk tujuan satu kali tertentu
  • Kode yang dapat ditulis dengan cepat dan mudah kapan pun dibutuhkan
  • Kode sekali pakai

• Naskah

  • Kode yang akan (mungkin) digunakan lebih dari sekali atau dua kali
  • Kode kompleks membutuhkan lebih dari pernyataan "beberapa"
  • Kode yang perlu dipelihara oleh orang lain
  • Kode untuk dipahami oleh orang lain
  • Kode yang akan dijalankan tanpa pengawasan (misalnya, dari cron)

Saya melihat cukup banyak pertanyaan di sini di unix.SE meminta one-liner untuk melakukan tugas tertentu. Dengan menggunakan contoh saya di atas, saya pikir yang kedua jauh lebih dapat dipahami daripada yang pertama, dan karena itu pembaca dapat belajar lebih banyak darinya. Satu solusi dapat dengan mudah diturunkan dari yang lain sehingga untuk kepentingan keterbacaan (untuk pembaca masa depan) kita mungkin harus menghindari memberikan kode yang diperas dalam satu baris untuk apa pun selain solusi yang paling sepele.

Tulis skrip ketika:

• diperlukan lebih banyak kode
• Anda menghargai keterbacaan
• perlu / bermanfaat untuk menambahkan komentar, untuk menunjukkan apa yang dilakukan kode
• Anda harus melewati parameter
• Anda ingin skrip dijalankan di lingkungannya sendiri (variabel, dll.)
• Anda mungkin akan menggunakan kembali / mengadaptasi kode untuk beberapa tujuan yang lebih kompleks

Tulis satu kalimat saat:

• hanya sejumlah kecil kode yang diperlukan
• Anda ingin mengakses variabel yang ditentukan dalam shell saat ini
• Anda memerlukan solusi cepat & kotor

Ketika serangkaian perintah yang diperlukan cukup pendek dan / atau menghasilkan hasil yang bisa digunakan sebagai bagian dari pipa yang lebih besar atau alias perintah, itu mungkin merupakan one-liner yang bagus.

Pada dasarnya, saya pikir one-liner biasanya adalah hal-hal yang seorang administrator sistem berpengalaman yang akrab dengan masalah dan perintah yang digunakan mungkin menulis di tempat, tanpa terlalu banyak berpikir.

Ketika one-liner menjadi terlalu panjang atau melibatkan lebih dari kondisional atau loop yang sangat sederhana, biasanya lebih baik untuk menuliskannya sebagai skrip multi-baris atau fungsi shell, agar mudah dibaca. Juga, jika itu adalah sesuatu yang Anda tulis untuk digunakan lagi dan lagi, atau sesuatu yang akan digunakan (dan mungkin merepotkan) oleh orang lain, Anda harus bersedia meluangkan waktu untuk menulis solusi menjadi jelas (er), berkomentar, bentuk naskah.

Dalam Python, lekukan adalah bagian dari sintaksis, jadi Anda benar-benar tidak dapat menggunakan fitur-fitur bahasa sepenuhnya jika Anda menulis satu-liner.

Perl dan awk one-liner sering menggunakan kekuatan mentah ekspresi reguler. Tetapi beberapa menyebut ekspresi reguler sebagai Bahasa Hanya-Tulis, tidak sepenuhnya tanpa alasan. Menulis skrip multi-baris memungkinkan Anda menulis dalam komentar untuk menggambarkan apa yang seharusnya dilakukan ekspresi reguler tertentu, yang akan sangat membantu ketika Anda melihat skrip lagi, setelah melakukan hal-hal lain selama enam bulan di antaranya.

Ini pada dasarnya adalah pertanyaan yang sangat berbasis pendapat, karena melibatkan pengukuran berapa kompleksitas yang dapat diterima dan timbal balik antara keterbacaan dan kekompakan; semua ini adalah masalah penilaian pribadi. Bahkan pilihan bahasa dapat bergantung pada masalah pribadi: jika suatu bahasa tertentu secara teoritis akan optimal untuk masalah tertentu, tetapi Anda tidak terbiasa dengan itu, dan sudah tahu bagaimana menyelesaikan masalah dengan beberapa bahasa lain, Anda dapat memilih bahasa yang akrab untuk menyelesaikan pekerjaan dengan cepat dan dengan upaya minimum, meskipun solusi mungkin agak tidak efisien.

Yang terbaik sering kali adalah musuh yang cukup baik , dan ini berlaku sangat banyak di sini.

Dan jika Anda terbiasa dengan Perl, Anda mungkin sudah pernah mendengar tentang TMTOWTDI: Ada Lebih dari Satu Cara Untuk Melakukannya.

Harap dicatat bahwa ini adalah pendapat pribadi; bawa dengan sebutir garam.

1. Jika perintah itu pas di dalam, katakanlah, 80 karakter, gunakan one-liner. Baris perintah yang panjang sulit untuk dikerjakan. Ada juga masalah pengulangan, lihat # 2

2. Jika Anda perlu menjalankan perintah lebih dari satu kali, gunakan skrip. Selain itu, gunakan one-liner, asalkan syarat # 1 terpenuhi.

3. Ini sangat subyektif, tapi ya, saya melihat shell, Perl atau awk sebagai alat bantu saya untuk one-liners.
4. Lihat # 1, # 2, # 3.

Saya melihat dan menggunakan one-liner sebagai alat pengembangan sementara untuk mengedit berulang kali sampai ia melakukan apa yang saya inginkan, atau saya mengerti bagaimana beberapa kehalusan dari sebuah sub-perintah bekerja.

Kemudian akan dicatat (dan dijelaskan) dalam file teks pada subjek yang saya selidiki, atau dibersihkan menjadi skrip yang dimasukkan ke dalam PATH bin pribadi saya, mungkin untuk penyempurnaan lebih lanjut, parameterisasi dan sebagainya. Biasanya, satu baris akan dipecah menjadi lebih mudah dibaca, bahkan jika tidak ada perubahan lain yang dibuat, atau saya tidak pernah menggunakan skrip lagi.

Saya menetapkan histori shell saya menjadi lebih dari 5000 baris, dengan histori terpisah per terminal, dan per login pada remote dan seterusnya. Saya benci tidak dapat menemukan dalam perintah ini satu baris perintah yang saya kembangkan beberapa minggu lalu dan tidak berpikir saya akan membutuhkan lagi, maka strategi saya.

Terkadang, seluruh kelompok perintah perlu melakukan sesuatu, seperti mengonfigurasi beberapa perangkat keras; pada akhirnya saya menyalin semuanya dari sejarah, membersihkannya secara minimal, dan menambahkannya ke skrip shell RUNMEseperti catatan tentang apa yang saya lakukan, tetapi juga agar mereka hampir siap untuk digunakan lagi oleh orang lain. (Inilah sebabnya saya menemukan alat yang hanya menyediakan GUI untuk mengkonfigurasikannya sedemikian menyakitkan.) Saya menemukan ini keuntungan luar biasa dalam efisiensi, karena begitu sering sesuatu yang Anda harapkan untuk dilakukan hanya sekali, harus dilakukan lagi 5 kali .. .

Saya ingin orang-orang di tim saya menulis skrip untuk operasi apa pun yang mungkin perlu dilakukan lebih dari satu kali (yaitu "alur kerja" atau "saluran pipa"), dan untuk tugas apa pun yang harus didokumentasikan (biasanya hal-hal seperti "modifikasi hal-hal tertentu dalam beberapa dataset untuk memperbaiki data yang diberikan secara tidak benar" dalam kasus kami). Selain itu, "one-liners" atau skrip tidak terlalu penting.

Gagal mendokumentasikan alur kerja dengan benar (sebagai skrip atau yang setara) mempersulit memperkenalkan staf baru pada suatu proyek, dan juga membuat lebih sulit untuk mentransisikan orang keluar dari suatu proyek. Selain itu membuat semua jenis audit sulit, dan melacak bug mungkin tidak mungkin.

Ini terlepas dari bahasa apa yang digunakan untuk pemrograman.

Tempat kerja lain mungkin memiliki kebiasaan atau harapan yang serupa / berbeda, bahkan mungkin ditulis.

Di rumah, Anda melakukan apa pun yang Anda suka.

Sebagai contoh, saya menulis skrip segera setelah saya melakukan sesuatu yang non-sepele di shell, seperti sebelum mengirimkan jawaban untuk pertanyaan U&L, atau setiap kali saya perlu menguji masing-masing komponen perintah atau serangkaian perintah sebelum menjalankannya "untuk nyata".

Saya juga menulis skrip untuk tugas berulang yang saya benar-benar ingin lakukan dengan cara yang sama setiap kali, bahkan jika mereka sederhana, seperti

• memperbarui sistem OpenBSD saya dan semua paket yang terinstal (ini datang ke tiga perintah pendek, dan beberapa lainnya untuk housekeeping, dikumpulkan dalam skrip pendek), atau
• mencadangkan sistem saya ke penyimpanan di luar lokasi (pada dasarnya satu perintah, tetapi sekali lagi dengan cukup banyak pembersihan dan skrip juga memungkinkan saya untuk melakukan perbedaan di antara snapshot, dll., dan perlu bekerja sedikit berbeda pada sistem yang berbeda, dan Saya menjalankannya dari pekerjaan cron), atau
• mengambil surat (sekali lagi, pada dasarnya satu perintah, tapi saya ingin itu berperilaku berbeda ketika dipanggil sebagai tugas cron dan ketika saya menggunakannya dari baris perintah, dan itu seharusnya tidak mencoba untuk mengambil surat dalam beberapa keadaan, dan itu menulis pesan log pendek ke file).

Saya menggunakan fungsi shell (sangat jarang alias) untuk kenyamanan dalam shell interaktif, misalnya untuk menambahkan opsi ke perintah tertentu secara default ( -Funtuk ls) atau untuk membuat variasi khusus dari beberapa perintah (di pmansini adalah manperintah yang hanya melihat manual POSIX, misalnya) .

Sepertinya saya memegang pandangan minoritas tentang ini.

Istilah "skrip" sengaja dibuat membingungkan, singkirkan. Ini adalah perangkat lunak yang Anda tulis di sana, bahkan jika Anda hanya menggunakan bashdan awk.

Dalam sebuah tim, saya lebih suka menulis perangkat lunak dengan proses peninjauan kode yang diberlakukan oleh alat (github / gitlab / gerrit). Ini memberikan kontrol versi sebagai bonus. Jika Anda memiliki banyak sistem, tambahkan alat penyebaran berkelanjutan. Dan beberapa suite tes, jika sistem target penting. Saya tidak religius tentang ini, tetapi menimbang manfaat dan biayanya.

Jika Anda memiliki tim admin, yang paling sederhana vim /root/bin/x.shadalah sebagian besar bencana dalam hal komunikasi terkait perubahan, keterbacaan kode, dan distribusi lintas-sistem. Seringkali satu kerusakan serius menghabiskan lebih banyak waktu / uang daripada proses yang seharusnya "berat".

Saya lebih suka one-liners sebenarnya untuk apa pun yang tidak pantas proses "berat" itu. Mereka dapat digunakan kembali dengan cepat, dengan beberapa penekanan tombol, jika Anda tahu cara menggunakan riwayat shell Anda secara efektif; mudah disisipkan di antara sistem yang tidak terkait (mis. pelanggan yang berbeda).

Perbedaan penting antara (tidak ditinjau!) Satu-liners dan perangkat lunak yang ditinjau ("skrip"): tanggung jawab sepenuhnya berada di tangan Anda ketika Anda menjalankan satu-liner. Anda tidak pernah bisa berkata pada diri sendiri, "Saya baru saja menemukan satu-liner ini di suatu tempat, saya menjalankannya tanpa memahami, apa yang terjadi selanjutnya bukan salah saya" - Anda tahu Anda menjalankan bit-of-software yang tidak ditinjau dan belum diuji, jadi itu adalah kesalahan Anda. Pastikan itu cukup kecil sehingga Anda dapat melihat hasilnya - terkutuklah jika tidak.

Anda kadang-kadang memerlukan pendekatan sederhana ini, dan mengatur bilah di sekitar satu baris teks berfungsi dengan baik dalam praktiknya (yaitu batas antara kode yang ditinjau dan yang tidak direview). Beberapa one-liner saya terlihat sangat panjang, tetapi mereka bekerja secara efektif untuk saya. Selama saya grok mereka dan saya tidak mendorongnya ke lebih banyak kolega junior, semua baik-baik saja. Saat saya perlu membagikannya - saya melalui proses pengembangan perangkat lunak standar.

Saya harus mengatakan saya agak ngeri dengan implikasi dari bagian pertama dari pertanyaan. Bahasa scripting Unix adalah bahasa pemrograman lengkap, dan bahasa pemrograman adalah bahasa , yang berarti bahwa mereka hampir dapat ditempa dan fleksibel seperti bahasa manusia. Dan salah satu keunggulan "kelenturan dan fleksibilitas tak terbatas" adalah bahwa hampir tidak pernah ada "satu cara yang benar" untuk mengekspresikan sesuatu - ada banyak cara, dan ini adalah hal yang baik! Jadi, ya, tentu saja ini masalah preferensi pribadi, dan tidak ada yang salah dengan itu. Siapa pun yang mengatakan hanya ada satu cara untuk melakukan sesuatu,

Sekali waktu, saya sendiri ~/binadalah penuh dari "berguna" script kecil yang kutulis. Tetapi saya menyadari bahwa kebanyakan dari mereka terbiasa pada hari saya menulisnya, dan tidak pernah lagi. Jadi semakin banyak waktu yang berlalu, semakin kecil bindirektori saya .

Saya tidak berpikir ada yang salah dengan menulis skrip. Jika Anda membayangkan bahwa Anda atau orang lain mungkin menggunakannya lagi, tentu saja, tulis sebuah skrip. Jika Anda ingin "merekayasa dengan benar" sebuah skrip yang mendukung untuk itu, tentu saja, lakukanlah. (Bahkan jika tidak ada yang pernah menggunakannya, menulis itu praktik yang baik.)

Alasan saya tidak lagi menulis skrip (dan, saya kira, mendukung "satu kalimat"):

• binkekacauan direktori memang memiliki biaya. Saya tidak meletakkan barang-barang di sana lagi kecuali mereka benar-benar milik di sana.
• Bahasa scripting yang saya gunakan adalah bahasa yang saya gunakan ; Saya benar-benar lancar dengan mereka sekarang. Mengetik ulang satu baris setiap kali saya membutuhkannya tidak terasa seperti pekerjaan; Saya tidak merasakan mandat untuk menyimpan dan menyimpan dan menggunakan skrip hanya untuk meringankan beban mengetik. (Antara lain, pada titik tertentu beban mengetik ulang menjadi kurang dari beban memori mengingat apa script itu.)
• Alasan lain mengetik ulang hal-hal yang tidak terasa seperti beban adalah: sejarah perintah. Ada banyak one-liner yang belum saya ungkapkan sebagai skrip, meskipun saya menggunakannya setiap hari - tetapi saya tidak perlu mengetik ulang; Saya hanya mengingat mereka dari sejarah. Dengan cara itu mereka semacam skrip atau alias orang miskin.

Saya percaya bahwa sebagian besar waktu permintaan untuk "satu-liner" sebenarnya adalah permintaan untuk "suara", yaitu:

Dalam konteks jurnalisme, gigitan suara ditandai dengan frasa atau kalimat pendek yang menangkap inti dari apa yang pembicara katakan, dan digunakan untuk merangkum informasi ...

Orang ingin dan meminta kode terpendek yang menunjukkan solusi untuk pertanyaan yang diajukan.

Kadang-kadang, tidak ada cara untuk mengurangi pidato menjadi "suara menggigit" dan juga tidak mungkin untuk mengurangi skrip menjadi "satu baris" pendek. Dalam kasus seperti itu, satu-satunya jawaban yang mungkin adalah naskah.

Dan, secara umum, "gigitan suara" tidak pernah merupakan pengganti yang baik dari keseluruhan pidato. Jadi, "satu garis" pada umumnya hanya baik untuk menyampaikan ide atau untuk memberikan contoh praktis dari ide itu. Kemudian, setelah ide dipahami, itu harus diperluas (diterapkan) dalam sebuah skrip.

Jadi, tulis "satu garis" untuk menyampaikan ide atau konsep.

Tulis kode umum Anda sebagai skrip lengkap bukan satu baris.

Anda bertanya tentang "ketakutan dan penghinaan terhadap skrip". Ini disebabkan oleh situasi Q + A, di mana seringkali jawabannya mengatakan: Ini membutuhkan langkah ini dan ini, tetapi saya juga dapat meletakkannya dalam satu baris (sehingga Anda dapat menyalinnya dan menggunakannya sebagai perintah sederhana yang panjang).

Kadang-kadang Anda hanya bisa menebak apakah Q lebih baik dilayani oleh solusi salin tempel yang cepat dan kotor, atau jika skrip "bagus" tepat seperti yang perlu dipahami oleh Q.

Banyak pro dan kontra di sini benar, tetapi tetap saja mereka kehilangan intinya. Saya bahkan akan mengatakan definisi dalam Q tidak membantu.

File histori shell adalah "satu liner", tetapi masih tersimpan. Fungsi bash operate-and-get-next (C-o)bahkan memungkinkan Anda mengulanginya secara semi-otomatis.

Saya hampir tidak melihat fungsi kata yang disebutkan. Itulah cara untuk menyimpan "skrip" dan "satu baris". Dan dengan beberapa penekanan tombol, Anda dapat beralih di antara kedua format. Sebuah perintah majemuk sering dapat cocok baik.

history -r fileadalah cara membaca satu atau banyak baris perintah (dan komentar) dari file apa pun, bukan hanya dari file riwayat default. Hanya butuh sedikit pengorganisasian. Anda tidak harus bergantung pada ukuran file histori yang besar dan pencarian histori untuk mengambil (beberapa) versi baris perintah.

Fungsi harus didefinisikan dengan cara yang sama. Sebagai permulaan, masukkan thisfunc() {...}file "fungsi" di dir rumah Anda, dan sumber itu. Ya ini beberapa overhead, tetapi itu adalah solusi umum.

Jika Anda menyimpan setiap baris perintah dan setiap variasi skrip dalam file yang terpisah, itu adalah pemborosan (secara teoritis, tetapi objektif) dari blok sistem file.

Satu liner tidak memiliki apa pun yang cepat dan kotor dengan sendirinya. Ini lebih merupakan bagian copy-paste yang sedikit disukai, dan bagaimana kita hanya mengandalkan sejarah perintah untuk menyimpannya untuk kita.

@sitaram: one liner Anda benar-benar memiliki fitur tidak-turel : garis shebang, baris baru, empat panggilan utilitas - dua di antaranya adalah "program". Saya pikir skrip perl asli tampak lebih bagus dan berlari lebih cepat dan tidak membuang-buang byte dengan menyebar pada 60 baris. Dan perl juga memungkinkan Anda memeras sedikit.

Bagi saya, itulah jenis kapal yang harus dihindari. Apakah Anda ingin itu (ditempelkan) di baris perintah Anda? Tidak, dan kemudian, jika Anda menyimpannya dalam file (tidak peduli skrip atau fungsi apa pun), Anda mungkin akan menginvestasikan dua atau tiga baris-byte baru agar terlihat --- bagus.

10 menit. kemudian: Saya hanya ingin memeriksa apakah saya dapat mengatakan "dua program sed" atau "dua substitusi / panggilan". Tapi jawaban sitaram hilang. Balasan saya masih masuk akal, saya harap.