skrip satu baris vs

25

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.

cas
sumber
4
Mengenai Python, umumnya buruk untuk one-liners karena spasi putih adalah bagian dari sintaksis, termasuk lekukan dan baris baru . Selain itu, ini lebih verbal dan eksplisit daripada kebanyakan bahasa umum lainnya.
wjandrea
2
Apa pun yang saya punya untuk google (beberapa regex, biasanya) dan dapat digunakan kembali dalam beberapa bentuk atau varian, saya akan menyimpan dalam file skrip di cloud (dropbox, google cloud, apa pun). Komentar berisi kata kunci yang saya tahu akan saya gunakan ketika saya membutuhkannya lagi. Menghemat 5 + menit menimbang ulang pilihan saya antara berbagai jawaban yang sama, dan menghindari jebakan, atau membangun varian yang diperlukan karena saya tidak menemukan varian yang ditulis dengan baik yang saya butuhkan.
user3445853
3
@wjandrea Untuk menambahkan: regexes. Perl memiliki sintaks khusus untuk mereka yang mencakup operasi untuk melakukan dll. Dalam python Anda memerlukan fungsi panggilan impor dan tulis dengan string literal sebagai argumen yang membutuhkan lebih banyak karakter. Kebanyakan one-liners menggunakan banyak regex untuk memanipulasi teks jadi ini adalah "masalah besar".
Giacomo Alzetta
1
@wjandrea Python tidak buruk untuk one-liners, tidak dalam arti tidak bisa menulis satu. Rata-rata saya bisa mengubah skrip baris 4-5 menjadi satu-baris. Tapi seperti yang Anda sebutkan, ini lebih eksplisit daripada bahasa lain (yang IMHO itu salah satu kelebihan Python). Jadi mereka dapat masuk ke dalam penghitungan karakter ganda atau tiga kali lipat daripada mengatakan Perl atau awk (yang juga tidak perlu mengimpor beberapa perpustakaan tidak seperti Python), dan itulah yang dikeluhkan kebanyakan orang - panjangnya satu kalimat. Tapi sekali lagi, IMHO itu sepele untuk berdebat tentang jumlah karakter; jika sesuatu bekerja - berfungsi
Sergiy Kolodyazhnyy

Jawaban:

33

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.

roaima
sumber
Itu adalah contoh praktis yang bagus tentang bagaimana one-liner cepat dan kotor dapat berkembang menjadi skrip yang lebih kuat.
Anthony G - keadilan untuk Monica
Ini awal yang baik, tetapi ada satu kemungkinan lain. Saya memiliki beberapa hal yang berguna untuk digunakan lebih dari sekali atau dua kali, tetapi mungkin tidak pada mesin yang sama. Saya menyimpannya dalam file teks yang saya buka setiap saat di komputer kerja saya, sehingga saya dapat dengan cepat menyalinnya dan menempelkannya ke klien SSH saya (atau prompt perintah pada server Windows, dalam hal ini). Ini belum tentu "satu liners" atau saya tidak melalui upaya menyimpannya dalam file sebagai "skrip". Saya menyebutnya "resep".
Monty Harder
@MontyHarder Untuk kasus seperti itu saya cenderung menyimpannya sebagai skrip kemudian menyimpannya dalam git repo. Saya kemudian dapat menginstalnya pada mesin apa pun yang saya butuhkan melalui klon git sederhana. Itu untuk pekerjaan. Untuk penggunaan pribadi, saya tidak pernah menulis kode dalam file "resep" (saya tidak menggunakan cuplikan github misalnya). Saya menyimpan semua skrip saya di direktori $ HOME / bin yang saya simpan sejak kuliah di tahun 1997 (di universitas SunOS). Saya mendapat ide dari novel Neuromancer di mana protagonis dan antagonis menyimpan skrip / program pribadi untuk digunakan sebagai senjata
slebetman
1
Meskipun itu jelas bersinggungan dengan diskusi yang sebenarnya, dalam skrip contoh Anda, Anda dapat menggunakannya set -- host1 host2 host3saat itu for h in "$@"(atau hanya for h), yang akan membuat skrip POSIX-portable. :-)
wchargin
2
Saya suka poin tentang membuat kode lebih mudah dibaca untuk OP dan pemirsa belajar. Terbaik untuk melakukan keduanya dalam jawaban, tetapi saya merasa lebih mudah untuk menggabungkan skrip vs mendekonstruksi satu liner secara pribadi.
FreeSoftwareServers
10

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
dr01
sumber
Biasanya mudah untuk memodifikasi hal-hal yang dijalankan oleh satu-liner. Poin "pass parameter" untuk skrip mungkin harus "Anda ingin mengemasnya agar mudah digunakan nanti". Saya telah menulis "one-liners" yang mencakup mendefinisikan fungsi shell dan memanggilnya. Meskipun sekarang saya berpikir tentang itu, bahwa seseorang telah menetap setelah beberapa iterasi dan saya harus meletakkannya dalam naskah.
Peter Cordes
9

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.

telcoM
sumber
ditambah satu untuk menyebutkan "atau fungsi shell"
glenn jackman
7

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.
schaiba
sumber
3
Saya menyukai jawaban yang saya lihat sejauh ini. Saya terutama menyukai poin 1 Anda - mengedit adalah salah satu hal yang saya rencanakan untuk disebutkan dalam jawaban saya - bahkan dengan ^ X ^ E, jauh lebih mudah dan jauh lebih menyenangkan untuk mengedit skrip di editor favorit Anda daripada mengedit pada perintah- baris.
cas
2
Terpilih meskipun poin 4 sepertinya tidak ada gunanya. :)
Anthony G - keadilan untuk Monica
@cas: dengan tombol panah kontrol (atau alt + f / alt + b) Anda dapat bergerak dalam satu-liner dengan sangat cepat. Terutama jika Anda memiliki pengaturan auto-repeat di 50 / detik dengan penundaan singkat seperti 220ms. Anda juga dapat menggunakan pencarian control-s / control-r dalam satu-liner, meskipun itu dapat membawa Anda kembali ke sejarah lain. Jika Anda hebat dengan control-w, alt + backspace, alt + d, dan control-y, Anda dapat melakukan banyak hal hanya dengan pergerakan kursor keyboard.
Peter Cordes
Juga, IIRC beberapa shell (seperti ZSH saya pikir) memiliki keybind untuk memanggil editor pada baris perintah saat ini, memungkinkan Anda untuk menulis "satu-liner" di editor favorit Anda dan dengan mudah memasukkannya ke dalam sejarah-perintah untuk kemajuan lebih lanjut. panah dan pengeditan. (Mampu memodifikasinya untuk dijalankan kembali adalah apa yang membuat one-liners bagus, vs menangani opsi baris perintah dalam skrip.) IIRC, bash juga memiliki edit eksternal, tetapi tidak terikat pada apa pun secara default.
Peter Cordes
@PeterCordes menggerakkan kursor dengan sangat cepat bahkan tidak mulai membandingkan dengan apa yang dapat Anda lakukan di editor yang layak seperti vi / vim. btw, ^ X ^ E memanggil $ EDITOR atau $ VISUAL dalam bash (dan beberapa shell lainnya. zsh juga, saya pikir. dapat dikonfigurasi). ini adalah cara yang baik untuk mengubah kekacauan yang tidak dapat dibaca yang saya buat menjadi sesuatu yang dapat dipahami dengan memasukkan umpan baris dan lekukan - mudah tersesat di kawat gigi atau kurung bersarang tanpa itu. BTW windows terminal saya memiliki lebar lebih dari 250 karakter, jadi one-liner saya bisa menjadi sangat panjang bahkan tanpa membungkus.
cas
7

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 .. .

meuh
sumber
1
+1 one-liners bagus untuk panah atas dan edit, vs. menerapkan opsi baris perintah untuk skrip untuk mengontrol apa yang dilakukannya secara terpisah dari apa yang beroperasi. mis. ubah lnvs. ln -suntuk tautan keras vs. lunak dalam satu-liner yang melilitkan beberapa file.
Peter Cordes
5

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) .

Kusalananda
sumber
5

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.

kubanczyk
sumber
1
poin bagus: saya suka istilah "program" lebih dari "skrip" sendiri.
glenn jackman
5

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.
Steve Summit
sumber
4

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.

Ishak
sumber
1

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.

rastafile
sumber