Belajar BASH Scripting - Sejarah, Latar Belakang & Mengapa BASH

#Pendahuluan

Setelah di episode 0 sebelumnya kita memastikan environment siap — skill dasar Linux CLI, environment dengan BASH 4.0+/5.0+, dan verifikasi bahwa bash --version berjalan normal — pada episode kali ini kita akan mundur sejenak untuk menjawab pertanyaan yang jarang diajukan tapi sangat menentukan: dari mana BASH berasal, dan mengapa ia menjadi standar dunia?

Pertanyaan ini bukan sekadar trivia sejarah. Memahami latar belakang BASH menjawab tiga pertanyaan praktis yang akan menghantui kalian sepanjang karier: (1) mengapa skrip yang berjalan di #!/bin/bash bisa berbeda hasilnya dengan #!/bin/sh, (2) kapan kalian harus menulis BASH dan kapan lebih bijak memakai Python atau Go, dan (3) mengapa hampir semua server di internet — dari yang menjalankan WordPress sampai bank — masih setia pada shell yang lahir lebih dari tiga dekade lalu. Seperti memahami sejarah sebuah bahasa, memahami sejarah shell membuat kalian tidak hanya bisa memakai, tapi tahu kapan memakai.

Di episode ini kita akan menelusuri evolusi shell dari Bourne Shell 1979 hingga shell-shell modern, membedah posisi BASH sebagai standar de facto, memahami perbedaan #!/bin/bash vs #!/bin/sh, membandingkan BASH dengan bahasa tingkat tinggi, dan menutup dengan miskonsepsi yang paling sering menyesatkan pemula.

#Evolusi Shell: Dari Bourne Shell ke BASH

Sebelum GUI dan desktop, komputer dioperasikan lewat teks. Shell — program yang membaca perintah dari keyboard dan meneruskannya ke sistem operasi — adalah "antarmuka" utama manusia dengan mesin. Sejarah shell adalah sejarah evolusi antarmuka itu.

#Bourne Shell (sh, 1979)

Pada tahun 1979, Stephen Bourne menulis Bourne Shell untuk UNIX Versi 7 di Bell Labs. Ini adalah titik balik: Bourne Shell bukan sekadar peluncur perintah, melainkan bahasa scripting yang sesungguhnya — mendukung variabel, kontrol alur (if, for, while), dan pemrosesan file. Sebelumnya, shell-shell di UNIX hanyalah eksekutor perintah sederhana.

Bourne Shell menjadi standar de facto scripting di UNIX karena ia terikat pada sistem operasi (bukan pada mesin tertentu) dan dirancang untuk skrip otomatis — bukan hanya interaktif. Hampir semua hal yang kalian anggap "cara menulis skrip" hari ini berakar pada Bourne Shell: sintaks if [ kondisi ]; then, for i in ...; do, dan # untuk komentar.

#C Shell (csh) dan Korn Shell (ksh)

Pada awal 1980-an muncul dua pesaing:

• C Shell (csh) ditulis Bill Joy di Berkeley. Sintaksnya meniru bahasa C — seperti if (kondisi) then dan variabel set x = 1. Ia populer di kalangan programmer interaktif, tapi dikenal buruk untuk scripting karena sintaks yang tidak konsisten.
• Korn Shell (ksh) ditulis David Korn pada 1983. Ia mengambil kelebihan Bourne Shell dan menambahkan fitur interaktif dari C Shell: riwayat perintah, alias, dan job control. ksh menjadi shell yang sangat dihormati di dunia komersial.

#Lahirnya BASH (1989)

Pada akhir 1980-an, proyek GNU (yang nanti menaungi Linux) membutuhkan shell bebas yang kompatibel dengan standar POSIX dan setara dengan Bourne Shell. Brian Fox menulis Bourne Again Shell — yang namanya adalah plesetan dari Bourne Shell — dan merilisnya pada tahun 1989. BASH mengambil warisan Bourne Shell, menambahkan fitur interaktif dari ksh dan csh, serta terus dikembangkan selama bertahun-tahun.

Saat Linux muncul pada 1991 dan mulai populer, BASH sudah menjadi shell default di hampir semua distribusi. Bukan karena ia paling cepat atau paling elegan — tapi karena ia bebas, tersedia di mana-mana, dan kompatibel ke belakang dengan skrip Bourne Shell yang sudah terlanjur ada di ribuan sistem.

#Mengapa BASH Menjadi Standar De Facto?

Jika ada zsh yang lebih "modern" dan fish yang lebih ramah pengguna, mengapa server masih memakai BASH? Jawabannya adalah kombinasi sejarah, ketersediaan, dan kekuatan ekosistem:

1. Default sejak awal. BASH adalah shell default di hampir semua distro Linux sejak 1990-an. Saat kalian login ke server, kalian sudah di BASH — tanpa langkah ekstra.

2. POSIX-compliant. BASH mematuhi standar POSIX (untuk mode sh), sehingga skrip yang ditulis untuknya bisa berjalan di banyak platform Unix-like. Standar ini membuat BASH menjadi "bahasa bersama" antar sistem.

3. Backward compatibility. Skrip Bourne Shell berusia 40 tahun masih bisa dijalankan BASH. Dalam dunia enterprise yang penuh sistem legacy, kompatibilitas ke belakang adalah nilai jual terbesar.

4. Ekosistem tooling raksasa. .bashrc, .bash_profile, fungsi, alias, dan sejuta tutorial di internet semuanya berasumsi BASH. Memilih shell lain berarti berenang melawan arus.

5. Cukup untuk 95% pekerjaan. Untuk otomasi administrasi — memproses log, memindahkan file, menjalankan perintah secara berkala — BASH lebih dari cukup.

#BASH vs zsh vs fish: Kapan BASH Tetap Pilihan Tepat?

• zsh luar biasa untuk interaktif — tab completion yang pintar, tema, plugin. macOS bahkan menjadikannya shell default. Namun sebagai bahasa scripting, perbedaannya dengan BASH tipis dan kebanyakan server tetap memakai BASH.
• fish sangat ramah pemula, tapi sintaksnya menyimpang jauh dari POSIX — skrip fish tidak berjalan di sh. Ini membuatnya tidak cocok untuk otomasi server yang portabel.
• BASH adalah "bahasa pasar" yang dipahami semua sistem. Untuk skrip yang berjalan di server produksi, BASH adalah pilihan paling aman dan paling dimengerti rekan kerja.

Bayangkan seperti bahasa lisan: zsh dan fish adalah dialek yang menyenangkan untuk ngobrol (interaktif), sedangkan BASH adalah bahasa formal yang dipahami semua orang di ruang rapat (server). Kalian boleh berinteraksi dengan dialek favorit, tapi dokumen resmi harus bahasa formal.

#POSIX Compliance & Portabilitas Shebang

Istilah POSIX (Portable Operating System Interface) muncul berulang kali — mari bedah. POSIX adalah keluarga standar yang didefinisikan IEEE untuk memastikan aplikasi dan skrip bisa berpindah antar sistem operasi Unix-like. Bagi kalian, yang penting adalah satu konsep: standar POSIX mendefinisikan perilaku shell yang "minimal" yang dijamin ada di mana-mana.

Konsekuensinya terlihat jelas di shebang — baris pertama skrip:

#!/bin/sh
#!/bin/bash
#!/usr/bin/env bash

• #!/bin/sh berarti "jalankan dengan shell POSIX". Di distro modern, /bin/sh sering di-link ke dash (Debian/Ubuntu) — shell yang ringan dan ketat POSIX, tanpa fitur BASH. Skrip dengan #!/bin/sh harus ditulis dengan disiplin POSIX.
• #!/bin/bash berarti "jalankan dengan BASH" — semua fitur BASH tersedia. Ini pilihan paling umum untuk skrip yang kita tulis di series ini.
• #!/usr/bin/env bash mencari bash dari $PATH — lebih portabel lintas platform di mana BASH tidak selalu berada di /bin. Trade-off-nya: env memakai PATH, sehingga bisa salah menunjuk di environment yang tidak biasa.

Praktik yang disarankan saat kalian menulis skrip yang harus berjalan di banyak sistem:

ls -l /bin/sh
bash --posix --version | head -1

lrwxrwxrwx 1 root root 4 ... /bin/sh -> dash
GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu)

Baris pertama menunjukkan bahwa /bin/sh di Ubuntu sebenarnya menunjuk ke dash — bukan BASH. Inilah mengapa "jalan di terminal tapi error di skrip" sering terjadi: skrip memakai shebang #!/bin/sh namun isinya penuh fitur BASH.

#BASH Scripting vs Bahasa Tingkat Tinggi

Pertanyaan klasik: bukankah lebih baik memakai Python atau Go? Jawabannya: tergantung konteks. BASH bukan lawan Python — keduanya alat untuk pekerjaan berbeda. Seperti obeng dan bor listrik: obeng lebih tepat untuk sekrup kecil di tempat sempit, bor untuk pekerjaan besar.

Aturan praktis dari para sysadmin senior:

1. Skrip yang merangkai perintah Linux → BASH. Jika 80% isinya memanggil cp, tar, systemctl, atau curl, maka BASH adalah pilihan paling ringkas dan jelas.
2. Skrip dengan logika kompleks → Python/Go. Jika ada parsing JSON mendalam, manipulasi string rumit, atau struktur data bertingkat, bahasa tingkat tinggi jauh lebih aman.
3. Keduanya sering dipakai bersama → BASH sebagai "orchestrator" yang memanggil tool, Python/Go sebagai "engine" untuk bagian berat. Ini pola umum di dunia nyata.

#!/bin/bash
# Backup harian: kompres, pindahkan, bersihkan yang lama
 
tar -czf /backup/$(date +%F)-data.tar.gz /var/www/data
rsync -a /backup/ /mnt/backup-server/
find /backup -name "*.tar.gz" -mtime +30 -delete

Skrip ini menuliskan niat dalam 4 baris yang langsung terbaca. Menerjemahkannya ke Python akan menghasilkan puluhan baris subprocess.run(...) — tanpa manfaat berarti. Inilah kekuatan BASH: keringkasan untuk tugas otomasi sistem.

#Miskonsepsi Umum

1. "BASH sama dengan terminal." Tidak. Terminal (emulator) hanyalah jendela tempat kalian mengetik; BASH adalah program yang berjalan di dalamnya dan menafsirkan perintah. Kalian bisa memakai terminal yang sama dengan shell berbeda — coba ketik zsh atau ksh untuk berpindah.

2. "BASH adalah bahasa pemrograman yang lemah, jadi tidak perlu belajar." Salah besar. BASH bukan untuk membangun aplikasi, tapi untuk otomasi — dan di dunia server, otomasi adalah separuh pekerjaan. Justru karena "sederhana", BASH adalah bahasa yang paling sering dieksekusi di dunia (setiap docker run, setiap cron, setiap boot).

3. "Skrip yang jalan di shell saya pasti jalan di server." Tidak otomatis. Perbedaan versi BASH, shebang yang salah, dan perbedaan perintah antar distro adalah sumber error paling umum. Selalu tulis dengan shebang eksplisit dan uji di environment target.

4. "Kalau bisa Python, buat apa BASH?" Karena keduanya bukan pesaing. Backup, log rotation, dan setup server adalah pekerjaan BASH; parsing JSON dan logika bisnis adalah pekerjaan Python. Memakai Python untuk cp adalah bor untuk sekrup — bisa, tapi tidak efisien.

5. "sh dan bash itu hal yang sama." Di Linux modern, tidak selalu. Seperti yang kita lihat, /bin/sh di Ubuntu menunjuk ke dash — interpreter POSIX tanpa fitur BASH. Menulis #!/bin/sh dengan isi ala BASH adalah resep error.

#Penutup

Pada episode 1 ini kita telah memahami bahwa BASH adalah hasil evolusi panjang: dari Bourne Shell (1979) yang memperkenalkan scripting, ksh dan csh sebagai pesaing, hingga BASH karya Brian Fox (1989) yang menang berkat posisinya sebagai shell default, kompatibilitas POSIX, dan backward compatibility. Kita juga membedah mengapa BASH menjadi standar de facto di server Linux, perbedaan krusial #!/bin/bash vs #!/bin/sh (dan mengapa /bin/sh di Ubuntu adalah dash), serta posisi BASH sebagai orchestrator yang berdampingan — bukan bersaing — dengan bahasa tingkat tinggi.

Inti yang harus kalian bawa:

• BASH lahir sebagai penerus Bourne Shell dan menang karena menjadi default, POSIX-compliant, dan kompatibel ke belakang.
• Server berbicara BASH, bukan zsh atau fish — kuasai bahasa pasarnya.
• #!/bin/bash (interpreter BASH) berbeda dengan #!/bin/sh (POSIX, sering dash).
• BASH unggul untuk otomasi sistem; Python/Go untuk logika kompleks.
• Jangan mencampurkan sh dan bash, dan selalu tulis shebang eksplisit.

Sekarang kalian tahu mengapa BASH ada. Di episode 2 selanjutnya kita akan langsung praktik: shebang, mode eksekusi, dan skrip pertama — menulis hello.sh, memahami chmod +x, dan membedah perbedaan mendasar antara ./hello.sh, bash hello.sh, dan source hello.sh yang akan menentukan cara kalian mendesain skrip ke depannya. Sampai jumpa di episode 2!