Program Shell Terbesar di Dunia

 (github.com/oils-for-unix)
4 poin oleh GN⁺ 2024-12-09 | 1 komentar | Bagikan ke WhatsApp
  • Wiki ini bukan sekadar daftar skrip panjang, melainkan kumpulan program Shell “substansial” yang ditulis dengan tangan dan bahkan memanfaatkan struktur data serta algoritme
  • Kriterianya umumnya lebih dari 5K baris, dan skrip yang dibuat otomatis atau skrip completion yang repetitif dikecualikan dari contoh inti
  • Contoh utamanya jauh melampaui persepsi umum tentang skrip Shell, seperti ble.sh 87K baris, kalua sekitar 56K SLoC/baris, Relax-and-Recover 35K baris, nb 26K baris, dan winetricks 22K baris
  • Daftar ini mencakup beragam tool yang benar-benar dipakai, termasuk editor baris interaktif, add-on OpenWRT, debugger Bash, tool pengujian TLS, implementasi Kubernetes, tool backup dan pemulihan, tool penerbitan sertifikat, serta monitor resource
  • Uji OSH “Wild” mem-parse lebih dari satu juta baris Shell, tetapi sebagian besar adalah program kecil dan definisi paket distro yang repetitif, sehingga dibedakan dari program Shell berukuran besar

Apa yang dimaksud dengan “program Shell besar”

  • Di sini, “biggest” bukan sekadar jumlah baris mentah, melainkan “substantial”, yaitu skala dan kompleksitas yang nyata
  • Yang termasuk pada dasarnya adalah skrip Shell yang ditulis dengan tangan
    • Skrip besar yang dihasilkan autoconf diperlakukan sebagai pengecualian
    • Artefak yang dibuat otomatis, seperti skrip coreutils 70K baris, tidak dianggap sebagai program Shell besar dalam arti substansial
  • Program Shell yang memakai struktur data dan algoritme sangat diperhatikan
    • bash-completion memang canggih, tetapi strukturnya repetitif—berisi fungsi yang relatif sederhana untuk tiap perintah di mesin Unix—sehingga lebih mirip contoh tandingan
  • Garis patokan kasarnya adalah lebih dari 5K baris
    • Program Shell terbesar yang tidak repetitif umumnya berada di kisaran 10K+ baris
    • Belum ada program yang terkonfirmasi melebihi 100K baris

Contoh program Shell terbesar

  • akinomyoga/ble.sh: total 87K baris, 63K LoC tanpa komentar
    • Ini adalah editor baris interaktif seperti fish yang ditulis dalam bash murni
    • File utama out/ble.sh berisi 39K baris, 29K LoC tanpa komentar; jika digabung dengan file modul, totalnya 80K+ baris
    • Banyak komentarnya berbahasa Jepang
    • Membaca raw bytes dari terminal dengan bind -x, mendekodenya sendiri memakai beberapa state machine eksplisit, serta memelihara dan memperbarui drawing buffer
    • Juga mencakup timing dan “fibers”
    • Detail terkait Shell parser ada di komentar issue 663, dan dinilai sebagai salah satu contoh pemanfaatan struktur data paling canggih di Shell
    • Ada upaya untuk menjalankannya di OSH, dan sebagian besar berhasil di-parse
    • Commit pertama pada 2015 berukuran 8K baris / 6K LoC, sementara pengembangan sebenarnya dimulai pada 2013
  • kalua: add-on OpenWRT yang ditulis dalam POSIX shell, sekitar 56K SLoC/baris
  • Relax-and-Recover: tool backup dan pemulihan dengan 35K baris, 24K LoC
    • Commit git pertama pada Maret 2009, saat itu 4K baris / 3K LoC
  • xwmx/nb: nb sendiri ditulis dalam bash dengan 26K baris, 22K LoC
    • Jika test bats dihitung sebagai bash, ada tambahan 91K baris, 61K LoC
    • Commit pertama pada 2014, dan riwayat commit aktif dimulai sejak awal 2016
  • vegardit/bash-funk: library Bash dengan total 27K baris, 24K LoC
    • Commit pertama pada Mei 2017, saat itu 10K baris / 8K LoC
  • winetricks: skrip Shell 22K baris yang menginstal berbagai program Windows di bawah Wine
  • drwetter/testssl.sh: berisi bash 21K baris dalam satu file
    • Tampaknya ditulis dengan tangan
    • Dimulai pada 2006 dengan beberapa perintah openssl
    • Tersandung issue #606 saat parsing
  • rkhunter: program Bourne shell 21K baris yang ditulis dari 2003 hingga 2018
  • Simplenetes: diperkenalkan sebagai “Kubernetes in 17K lines of Shell”
    • Ditandai sebagai contoh yang mengejutkan, tetapi tampaknya berstatus dormant
    • Terkait dengan Hacker News Thread
  • inxi 2.3.56: program bash 16K baris yang ditandai obsolete
    • Di-fork dari infobash pada 2008
    • Saat itu infobash berukuran 889 baris, dan infobash dimulai pada 2005
    • Mulai v2.9, inxi digantikan oleh implementasi Perl
  • bashdb: debugger Bash yang ditulis dalam bash sekitar 14K baris
  • romkatv/powerlevel10k: direktori internal/ berisi skrip zsh 12K baris
    • Selain itu ada config dan helper script 8K baris
    • Commit pertamanya pada 2014
  • dylanaraps/neofetch: program 10K baris yang ditulis dalam Bash 3.2 dan menampilkan informasi sistem
    • Juga bisa melakukan fitur menarik terkait gambar
    • Commit pertamanya pada 2015
  • distrobox: skrip bash lebih dari 7K baris yang memungkinkan penggunaan distribusi Linux apa pun di dalam terminal
  • acme.sh: skrip Shell 8K baris untuk menerbitkan dan memperbarui sertifikat

Implementasi yang menonjol meski ukurannya lebih kecil

  • bashforth: tidak terlalu besar, sekitar 3.800 baris, tetapi mengimplementasikan bahasa pemrograman sungguhan
    • Banyak whitespace dan komentar
  • yoda: sekitar setengah ukuran bashforth, tetapi mengimplementasikan interpreter dan compiler lengkap
    • Implementasi dari penulis yang sama, 20 tahun lebih muda, dengan lebih banyak fitur
    • Diberi komentar “What learned you have, unlearn you must!”

Program Shell penting lainnya

  • abcde / A Better CD Encoder: digunakan untuk CD ripping, sekitar 5,5K LoC
  • thc-segfault: 3,3K LoC, server pubnix yang sebagian besar dibuat dengan Bash
  • ffmpeg/configure: skrip configure FFmpeg yang ditulis dengan tangan, 8,4K LoC
  • ffhevc: wrapper Bash sepenuhnya buatan tangan untuk mengenkode video HEVC dengan FFmpeg dan libx265, 4K LoC
  • ffx264: wrapper Bash sepenuhnya buatan tangan untuk mengenkode video H.264/AVC dengan FFmpeg dan libx264, 3,9K LoC
  • h264enc: wrapper Bash sepenuhnya buatan tangan untuk mengenkode video H.264/AVC dengan MEncoder, 9,2K LoC
  • bashtop: monitor resource 5,3K LoC
  • halcyon: sistem instalasi aplikasi Haskell, 6,6K LoC
    • Kode buatan tangan yang memperhatikan semantic bash dan pemeriksaan error, dengan gaya unik yang terinspirasi dari functional programming
  • wordshell: sekitar 7K baris kode untuk mengelola beberapa situs WordPress dari command line
  • BaCon: sekitar 10K baris, mengonversi program yang ditulis dalam BASIC menjadi C
    • Ada dua implementasi: implementasi BASIC dan implementasi skrip Shell
  • FireHOL: skrip utama 9K baris, dengan tool FireQOS tambahan 3K baris
    • Bahasa sekaligus program eksekusi untuk membuat secure, stateful firewall dari konfigurasi yang mudah dibaca manusia
  • gxadmin: 11K LoC, kumpulan templated SQL query dan utilitas pemrosesan data untuk mengelola scientific workflow engine Galaxy
  • mulle-bashfunctions: library fungsi untuk bash/zsh sekitar 6K baris
    • Digunakan di mulle-sde, dan mulle-sde sendiri adalah skrip Shell 100K baris lainnya
  • x11docker: 11,6K baris, menjalankan aplikasi GUI di dalam container docker atau podman

Bahasa mirip Shell dan DSL

  • modernish: portable shell dialect yang ditulis dalam Shell
  • bats: DSL untuk menulis test dan menghasilkan kode bash
  • bashible: DSL mirip Ansible yang ditulis dalam bash
  • clash: framework berorientasi objek yang kompatibel dengan semua POSIX shell modern
  • bash Infinity: standard library dan framework boilerplate untuk bash

Program yang lebih kecil dan ekosistem terkait

  • Skrip Alpine, Aboriginal, dan Debian ditautkan ke blog post terpisah
  • Skrip completion berukuran besar, tetapi sering kali repetitif
    • Completion Zsh _git berisi 8,3K baris kode
    • git-completion.bash dan completion Docker juga disebut sebagai contoh
  • dyne/Tomb: skrip zsh sekitar 3.500 baris
  • Basalt: package manager full-featured yang ditulis dalam Bash murni
    • Skalanya beberapa ribu baris, tetapi memiliki rich ecosystem yang mencakup lebih dari 15 aplikasi dan library
    • bash-core: library yang memperluas builtin trap dan shopt, serta menambahkan stacktrace dan fitur kenyamanan penting
    • bash-object: library untuk membangun struktur data bersarang arbitrer dalam Bash murni, dengan hampir 200 test
    • bash-json: library untuk mem-parse dan mencetak JSON dalam Bash murni
  • tablespoon/fun/cli-clock: jam teks multi-baris yang ditulis dalam bash
  • json.bash / jb: tool command line sekaligus library bash untuk membuat JSON
    • Sekitar 1.700 baris, dengan test sekitar 3.000 baris

Uji OSH dan hal yang perlu diperhatikan dalam penggunaan Shell

  • OSH "Wild" Tests mem-parse lebih dari satu juta baris Shell
    • Sebagian besar adalah program kecil dan definisi paket distro yang repetitif seperti Alpine PKGBUILD dan Gentoo ebuild
  • Shell Programs That Run Under OSH ditautkan sebagai daftar program Shell yang berjalan di OSH
  • shell script are dangerous memperingatkan bahwa Shell adalah program untuk menangani bagian dalam sistem, baik sebagai konsol interaktif maupun non-interaktif; fiturnya banyak, sangat berbahaya, dan tidak dibuat untuk membangun aplikasi

Bacaan terkait

1 komentar

 
GN⁺ 2024-12-09
Komentar Hacker News
  • Sekitar 25 tahun lalu, saat bekerja di Sony, saya menangani proyek untuk memperbaiki sistem manajemen pesanan yang sangat lambat dan sering mati
    Setelah digali, OMS itu ternyata sekumpulan skrip shell raksasa yang berjalan di server AIX, sudah berevolusi selama lebih dari 10 tahun lalu dibiarkan begitu saja. Kodenya lebih dari 50 ribu baris; informasi pesanan, pembayaran, dan lainnya dipindahkan antarserver lewat FTP lalu di-parse dengan sed/awk yang rumit, sementara inventori juga dilacak sebagai file teks dan dipindahkan lewat FTP
    Saat itu Perl terlihat sebagai pilihan paling praktis untuk memindahkan kekacauan ini, jadi saya mulai dari bagian yang paling sederhana, menggantinya dengan modul-modul Perl kecil, lalu melakukan refactoring bertahap di dalam aplikasi Perl yang lebih besar. Dalam 3 bulan, semuanya menyusut menjadi sekitar 5 ribu baris Perl, dan kegagalan pada sistem lama hampir hilang sepenuhnya sementara kecepatannya naik 10–100 kali lipat. Mengerikan, tetapi sampai sekarang itu salah satu pekerjaan paling memuaskan yang pernah saya lakukan
    • Hanya 3 bulan, berarti menghapus 800 baris per hari
      Saya penasaran apakah Anda membaca seluruh kode lama dan memahaminya mendalam lalu mencocokkan perilakunya persis, atau membuang bagian-bagian besar dan menulis ulang sesuai pemahaman Anda tentang “seharusnya bekerja seperti ini”. Juga penasaran apakah memang banyak boilerplate yang bisa diganti dengan cepat
    • Untuk meredakan monster skrip shell seperti itu, Perl masih menjadi yang paling praktis sampai sekarang. Tcl juga pilihan yang bagus
  • Saya harus membongkar lagi hal-hal yang dulu pernah saya tulis
    Skrip pertama yang benar-benar besar yang saya tulis adalah installer sekitar 7 ribu baris untuk Enrust CA dan direktori, dan harus berjalan di hampir semua Unix pada masa itu. Awalnya tidak seperti itu, tetapi membesar mengikuti kebutuhan pelanggan
    Instalasinya sendiri tidak terlalu rumit, tetapi upgrade agak rumit, dan pada masa itu setiap Unix punya sedikit perbedaan pada semua utilitasnya. Sebagian besar skrip berisi kode untuk menemukan dan menangani perbedaan-perbedaan itu, serta deteksi kesalahan, pemulihan, rollback, dan manajemen paket serta dependensi yang sangat primitif
    Unix dari DEC, yang bukan Ultrix, adalah yang paling membingungkan. Butuh beberapa hari untuk menyadari bahwa semua utilitas command-line memotong output pada lebar kolom terminal, dan 30 tahun kemudian saya masih mengingatnya
    HP-UX punya breaking change di setiap rilis, dan kalau ingatan saya benar kami mendukung dari 6.5 sampai 11. Ultrix, pihak Novell, NeXT, dan Sequent hampir tidak saya ingat. Saya ingat AIX itu aneh, tetapi lupa alasannya. Tiga/empat OS dari Sun juga punya perbedaan, tetapi manualnya luar biasa dan paling bagus
    • Output yang terpotong pada lebar kolom itu terdengar benar-benar aneh. Saya penasaran apakah memang tidak ada fitur seperti scroll horizontal di terminal
    • Kalau Unix dari DEC, yang dimaksud OSF/1, Digital Unix, atau Tru64 Unix?
    • Saya juga pernah sampai ribuan baris, tetapi kira-kira hanya sekitar 2 ribu baris. Untungnya yang perlu didukung hanya Red Hat dan Ubuntu terbaru
    • Tahun lalu saya menjalankan wc pada binary utama dan library pendukung dari sebuah proyek, dan sampai sekarang jumlahnya 6.224 baris
      Itu adalah skrip untuk mengelola pipeline dengan jaminan linear yang terdiri dari kumpulan container berupa adapter protokol input, satu atau lebih filter, dan adapter protokol output. Tujuannya adalah membuatnya dapat digunakan oleh orang-orang yang, meski bukan ahli container atau protokol, tahu bagaimana mereka ingin file difilter dan ditransformasikan saat melewati pipeline
      Binary tingkat atasnya punya struktur dengan subfungsi seperti git [ git options ] < git action> [action options] atau systemctl. Ada juga subcommand yang menambahkan subcommand baru, membuat library yang dibutuhkan, dan mengisi lebih dulu definisi fungsi dari template. Template memiliki fungsi penggunaan singkat/panjang sehingga cbap -h atau cbap pipeline -h memberikan panduan yang berguna
      Ada subcommand untuk memanipulasi base image, komponen, dan pipeline. Sebagian besar kode dipakai untuk pengujian guna memastikan definisi komponen dan pipeline ditulis dengan benar. Pipeline memakai format yang hampir seperti TOML, jadi ada kode parsing TOML dan konversi section menjadi array; komponen berupa file key=value sederhana, jadi ada kode untuk mengekstrak sisi kiri/kanan dan memvalidasi skema
      Karena komponen pipeline bisa berbagi atribut, ada juga kode untuk menemukan atribut umum dari file var dan etc serta menetapkan atribut komponen. Ada banyak fungsi untuk memanipulasi user, group, direktori, dan FIFO sesuai kebutuhan keamanan. Saat pipeline dikonfigurasi, ia membuat dan menerapkan user, group, tipe SELinux, serta kategori MCS, lalu memetakannya ke file service yang menjalankan komponen, jadi ada banyak manipulasi systemd
      Kumpulan pemanggilan terbesar mungkin adalah fungsi-fungsi untuk mengambil dan mengatur atribut komponen, yang pada praktiknya atribut container. Untuk tiap atribut dibuat fungsi pengambil, fungsi validasi, dan versi inline di dalam pipeline agar definisi container berbasis data bisa dibuat sefleksibel mungkin
      Ada juga kode yang banyak memakai referensi Bash untuk mengatur variabel dari file, environment variable, dan command line, sehingga pengujian cepat bisa dilakukan. Tingkat penggunanya juga didukung dalam empat level: maintainer yang menangani kode itu sendiri, developer yang mengembangkan definisi komponen, integrator yang membuat pipeline dari komponen, dan operator yang menginstal pipeline; skrip ini bisa menyalin dan memaketkan dirinya sendiri untuk diekspor ke pengguna di tiap level
      Karena sistem target bisa berupa Linux apa pun, paket dibuat dan diekstrak dengan makeself. Misalnya, ketika integrator membuat definisi pipeline, sebuah file makeself dibuat, dan saat dijalankan di sistem target, ia membuat semua user, group, direktori, dan FIFO, yaitu IPC antar-komponen, menerapkan DAC/MAC, membuat file systemd, menyalin image ke tiap user, lalu menjalankan pipeline. Opsi hapus juga bisa membalikkan semua itu
      Ada sebagian seccomp juga, tetapi sedang berhenti sementara karena harus mencari keseimbangan antara allowlist dan blocklist. ShellCheck benar-benar saya gunakan secara menyeluruh
  • Saya pernah mempertimbangkan menulis interpreter untuk bahasa skrip saya, Lil, dengan Bash agar portabilitasnya maksimal, tetapi segera menyadari bahwa operasi floating-point akan sangat menyakitkan
    Tidak bisa mengharapkan bc/dc tersedia di semua lingkungan, dan beberapa mesin yang saya miliki memakai versi Bash lama sehingga dukungan associative array juga sangat terbatas. Sebagai kompromi saya menargetkan AWK; AWK adalah bahasa serbaguna yang jauh lebih nyaman daripada kebanyakan shell dan tersedia di mana-mana pada lingkungan POSIX: https://beyondloom.com/blog/lila.html
    • Saya juga pernah membuat bahasa dengan target shell, lalu mengetahui sendiri bahwa bc/dc tidak bisa diharapkan tersedia di semua lingkungan

Saya cukup terkejut karena sepertinya instalasi Ubuntu di WSL2 tidak menyertakan bc/dc. Untuk perhitungan floating point saya memakai AWK, tetapi caranya hanya dengan memanggilnya sebagai proses eksternal.

  • Sebagai orang yang beberapa kali menulis dan memelihara program Perl besar sepanjang karier, menurut saya ada alasan mengapa orang melakukan ini
    Bahasa seperti Java atau Python cocok ketika antarmuka dan format sudah terdefinisi, dan interaksi dengan OS hampir tidak ada. Jika memakai JSON/XML/YAML, atau berkomunikasi dengan database dan program lain lewat HTTP(S), itulah situasi ideal tempat bahasa-bahasa seperti ini bersinar
    Namun ketika berurusan dengan teks dalam jumlah besar dan interaksi OS, Java dan Python menjadi sangat menyakitkan. Sebaliknya, Shell/Perl terasa jauh lebih mudah untuk pekerjaan seperti ini
    Hampir semua tugas otomasi, antarmuka yang kacau dan tidak terstandardisasi, file teks/log, serta format data yang tidak terstruktur atau kurang terstruktur masuk ke kategori ini. Jika ditambah kompatibilitas mundur Perl, basis instalasi yang luas, dan performanya, praktis tidak ada alternatif selain Perl untuk pekerjaan seperti ini
    Saya sudah lama melihat bahwa salah satu alasan besar mengapa perusahaan besar sekarang mempekerjakan ribuan orang untuk pekerjaan manual yang sebenarnya bisa diotomasi secara sepele adalah karena penggunaan Perl menurun. Begitu mencoba membuat otomasi besar dengan Python atau Java, orang cepat menyerah karena muak dengan verbositas kode yang harus ditulis dan dipelihara, serta skala keseluruhannya

    • Saya sangat tidak setuju dengan klaim bahwa “ini karena Perl menghilang”. Menurut saya lebih tepatnya kompleksitas meningkat, pekerjaan orang Perl yang dulu menyambung-nyambungkan skrip menjadi pekerjaan penuh waktu, dan Perl sendiri pun punya batasan
      Jadi sekarang mungkin memang perlu tambahan tenaga kerja tetap yang mahal. Jika pengguna akhirnya memakai Windows, sudah ada opsi mirip Perl di desktop mereka. Itu adalah PowerShell, dan perannya mirip dengan Perl
    • Saya pernah mengerjakan otomasi besar dengan kode native. Dalam kasus seperti ini, efisiensi penting
      Bash+grep cenderung mengarah pada pola menjalankan proses baru untuk setiap baris teks. Agar efisien, pekerjaan harus diminimalkan, dan untuk itu diperlukan pemrosesan batch serta deduplikasi. Artinya data harus ditangani secara stateful sambil melacak konteks deduplikasi, dan itu lebih mudah dilakukan di bahasa pemrograman yang layak
      Bash+grep unggul untuk pemrosesan teks stateless, sehingga duplikasi pekerjaan mudah membesar. Cara lain untuk mengurangi pekerjaan adalah filtering yang akurat, dan ini lebih mudah diekspresikan secara imperatif dengan rapi di bahasa yang layak. grep dan regex sama sekali tidak cocok untuk tujuan seperti ini
      Jika memakai format berbasis baris, git akan menambahkan escaping agar bisa menerima apa pun, tetapi dukungannya tidak konsisten, dan ini bisa dinonaktifkan dengan meminta format string berakhiran null lewat opsi -z. Sepertinya Bash tidak punya cara untuk menangani ini, sementara di bahasa yang cukup low-level hal itu bisa ditangani secara alami. Selain itu, streaming bertahap juga memungkinkan tanpa harus memulai proses baru untuk setiap baris teks
      Sebagai bonus, satu codebase bisa dipakai untuk semua pekerjaan, entah di tengahnya ada HTTP atau hal lain
    • Setuju. Bahasa favorit saya adalah Python, tetapi untuk pekerjaan OS low-level tertentu bisa merepotkan atau tidak efisien. Karena itu saya membuat https://www.oilshell.org dan halaman wiki yang ditautkan
      Ada beberapa tautan sebagai konteks. “Apakah ini menciptakan ulang Perl?”: https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#a...
      “Unix shell seharusnya berevolusi seperti Perl 5, dengan opsi upgrade yang kompatibel, bukan big bang seperti Perl 6/Raku”: https://www.oilshell.org/blog/2020/07/blog-roadmap.html#the-...
      Tur YSH: https://www.oilshell.org/release/latest/doc/ysh-tour.html
    • Setelah menyadari bahwa Perl terpasang secara default di banyak sistem Linux dan BSD, saya mulai mempertimbangkan untuk mempelajari Perl 5 dengan serius. Setahu saya OpenBSD juga hadir dengan Perl terpasang
      Ini mungkin tidak terlihat seperti keunggulan besar sampai Anda bekerja di lingkungan tempat Anda tidak bisa memasang sesuatu dari internet, atau bahkan sama sekali tidak bisa mengakses internet

  • Masalah utama saat menulis program besar sebagai skrip Bash adalah bahwa bahasa skrip shell sejak awal memang tidak dirancang untuk kompleksitas
    Bash sangat baik untuk mengoordinasikan perintah kecil dan dengan cepat menyambungkan tool yang sudah ada secara eksploratif, tetapi begitu Bash mulai melewati beberapa ratus baris, berbagai keterbatasan yang membuat pemeliharaan jangka panjang dan skalabilitas menjadi merepotkan mulai bermunculan
    Pertama, keterbacaan menjadi masalah. Sintaks Bash bisa benar-benar sulit dipahami ketika membesar. Aturan scope variabelnya halus, penanganan error-nya primitif, dan pemrosesan string cepat menjadi berantakan. Akhirnya maintainer membuang waktu untuk menguraikan apa yang terjadi, dan sulit melakukan perubahan dengan percaya diri
    Berikutnya adalah kurangnya tooling yang kuat. Bahasa yang lebih matang memiliki tool analisis statis, linter, dan debugger yang membantu menangkap kesalahan umum lebih awal. Di Bash, hal-hal seperti ini tidak ada atau sangat terbatas. Tanpa pengaman seperti itu, program Bash besar lebih rentan terhadap error diam-diam, regresi, dan bug halus
    Pengujian juga menjadi masalah. Skrip Bash memang bisa diuji, tetapi prosesnya biasanya lebih merepotkan, dan menjadi lebih sulit jika ada logika atau struktur data yang kompleks. Saat menangani edge case seperti spasi dalam nama file atau kondisi lingkungan yang tidak terduga, akan muncul banyak kode defensif yang menyakitkan untuk diverifikasi
    Terakhir, ekosistemnya sendiri tidak dibuat untuk pengembangan Bash berskala besar. Anda kehilangan modularisasi, manajemen paket, penanganan dependensi terstandardisasi, dan pola pengembangan modern yang disediakan Python atau Go. Seiring waktu, kekurangan-kekurangan ini menumpuk dan memperlambat pekerjaan
    Memakai Bash untuk pekerjaan sekali jalan atau otomasi sederhana itu baik-baik saja. Itulah hal yang memang dikuasai Bash. Tetapi jika Anda berniat membangun sesuatu yang besar, biasanya lebih baik memakai bahasa yang dirancang untuk membuat dan memelihara aplikasi kompleks, dan dalam jangka panjang itu akan menghemat waktu meskipun kurva belajar atau setup awalnya sedikit lebih tinggi

  • Menggunakan ShellCheck sebagai linter bisa menangkap banyak jebakan umum. Bash/shell punya sangat banyak jebakan dan perilaku tak terduga, sehingga penulis Bash yang berpengalaman pun bisa terkena
    Namun Bash/shell menempati posisi unik dalam hierarki bahasa. Ia ada hampir di mana-mana dan kemungkinan besar masih akan ada 30 tahun lagi. Jika Anda menginginkan program yang berjalan hampir di mana saja dan masih bisa dijalankan 30 tahun lagi, shell/Bash adalah pilihan yang baik

    • Di tempat kerja sekarang saya sedang mengalami persis ini. Saya sedang membongkar Bash ribuan baris
      Ini juga bukan skrip yang ditulis sangat lama, jadi saya tidak tahu kenapa mereka memilih Bash. Skripnya berjalan, tetapi rasanya sesuatu bisa rusak hanya karena kita menatap kodenya dengan cara yang salah
    • Bash/ksh punya argumen debugging/tracing -x

  • Program shell manual terbesar yang dulu saya pakai secara rutin mungkin abcde (A Better CD Encoder), ukurannya sekitar 5.500 baris
    https://abcde.einval.com
    https://git.einval.com/cgi-bin/gitweb.cgi?p=abcde.git;a=blob...

    • Saya tidak bisa bilang sangat mengenalnya, tapi dulu itu salah satu tool yang direkomendasikan di What.CD. Teman-teman juga bilang Max ikut direkomendasikan: https://github.com/sbooth/Max
    • Saya pernah memakainya dan benar-benar berjalan dengan baik, juga cukup mudah digunakan. Saya sama sekali tidak tahu bahwa seluruhnya adalah satu skrip shell raksasa

  • Banyak dari program seperti ini benar-benar permata. Misalnya skrip rkhunter: kodenya cukup bagus, masih bisa ditingkatkan, dan juga merupakan gudang informasi
    Sebagian besar ukuran kode skrip seperti ini dipakai untuk memastikan utilitas yang dibutuhkan ada di berbagai platform, dan bekerja sesuai harapan dengan berbagai opsi command line. Ini titik paling menyakitkan bagi penulis skrip shell yang serius, bahkan lebih sulit daripada sinyal dan subprocess
    Kalau rkhunter ditulis dalam bahasa pemrograman yang “layak”, informasi seperti ini rasanya akan kurang transparan. Bisa saja terdorong masuk sebagai record dalam struktur data untuk di-query, atau berjalan melalui beberapa fungsi di atas struktur data bersarang, atau lebih buruk lagi, kombinasi method dan class. Log-nya pun mungkin dipecah menjadi JSON, dikompresi ke database, lalu harus diakses lewat method lain
    Karena skrip shell tidak punya alat-alat kompleks semacam itu, ia justru cenderung menampilkan apa yang terjadi apa adanya. Karena itu rkhunter juga berfungsi sebagai dokumentasi yang cukup bagus tentang berbagai exploit dan rootkit, dengan lebih sedikit kebutuhan untuk menggali dari file ke file, struktur ke struktur, database ke database

  • Klien FreeBSD Update adalah sekitar 3.600 baris kode sh
    Dibanding program lain yang disebutkan di sini memang tidak besar, tetapi menurut saya jumlah fungsinya sebagai “tool untuk memperbarui seluruh sistem operasi” cukup berbobot. Kode untuk membangun update tersebar di beberapa file, jadi jika digabungkan mungkin lebih banyak

  • “Cuma” 7,1 ribu baris, tetapi yang saya suka adalah skrip acme.sh yang dipakai untuk menerbitkan dan memperbarui sertifikat di Let’s Encrypt
    https://github.com/acmesh-official/acme.sh/blob/master/acme....

  • Kadang yang bisa dijamin tersedia memang hanya shell, dan ada situasi yang benar-benar membutuhkan portabilitas
    Namun secara umum, jika Anda punya aplikasi shell raksasa, mungkin Anda perlu memikirkan ulang pilihan hidup Anda

    • Masalahnya adalah “shell yang mana”. Bash jauh dari universal
      Selain itu, biasanya tidak banyak yang bisa dilakukan hanya dengan shell, dan perlu perintah seperti find, grep, sed, cat, head, tail, cut. Perintah-perintah ini juga punya masalah portabilitas masing-masing
      Menargetkan BusyBox mungkin merupakan pilihan terbaik, tetapi begitu keluar dari sistem Linux umum, menulis skrip Bourne shell yang portabel menjadi sulit atau hampir mustahil
    • Saya cukup sering mendengar hal seperti ini, dan saya sungguh penasaran seberapa sering sebenarnya ada shell, tetapi tidak ada compiler C, atau tidak bisa memasang compiler C lewat shell
      Jika ada compiler C saja, Anda bisa keluar dari shell dengan menulis program C untuk kemudian dirangkai oleh skrip shell, atau memasang bahasa skrip yang lebih baik seperti Lua. Pada titik ini, kasus yang benar-benar mengharuskan memakai shell saja terasa cukup niche