Untuk memulai skrip shell 'file.sh':
sh file.sh
bash file.sh
Opsi lain adalah mengatur izin yang dapat dieksekusi menggunakan perintah chmod:
chmod +x file.sh
Sekarang jalankan file .sh sebagai berikut:
./file.sh
Untuk menjalankan sh yang tidak dapat dieksekusi skrip, gunakan:
sh myscript
Untuk menjalankan bash yang tidak dapat dieksekusi skrip, gunakan:
bash myscript
Untuk memulai file yang dapat dieksekusi (yang merupakan file apa pun dengan izin yang dapat dieksekusi); Anda cukup menentukannya dengan jalurnya:
/foo/bar
/bin/bar
./bar
Untuk membuat skrip dapat dieksekusi, berikan izin yang diperlukan:
chmod +x bar
./bar
Saat file dapat dieksekusi, kernel bertanggung jawab untuk mencari tahu bagaimana mengeksekusinya. Untuk non-biner, ini dilakukan dengan melihat baris pertama file. Itu harus berisi hashbang :
#! /usr/bin/env bash
Hashbang memberi tahu kernel program apa yang harus dijalankan (dalam hal ini perintah /usr/bin/env dijalankan dengan argumen bash ). Kemudian, skrip diteruskan ke program (sebagai argumen kedua) bersama dengan semua argumen yang Anda berikan pada skrip sebagai argumen berikutnya.
Artinya setiap skrip yang dapat dieksekusi harus memiliki hashbang . Jika tidak, Anda tidak memberi tahu kernel apa itu itu , dan karena itu kernel tidak mengetahui program apa yang digunakan untuk menginterpretasikannya. Bisa jadi bash , perl , python , sh , atau sesuatu yang lain. (Pada kenyataannya, kernel akan sering menggunakan shell default pengguna untuk menginterpretasikan file, yang sangat berbahaya karena itu mungkin bukan penerjemah yang tepat sama sekali atau mungkin dapat menguraikan sebagian tetapi dengan perbedaan perilaku yang halus seperti ini kasus antara sh dan bash ).
Catatan tentang /usr/bin/env
Paling umum, Anda akan melihat poni hash seperti ini:
#!/bin/bash
Hasilnya kernel akan menjalankan program /bin/bash untuk menafsirkan naskah. Sayangnya, bash tidak selalu dikirimkan secara default, dan tidak selalu tersedia di /bin . Sedangkan pada mesin Linux biasanya demikian, ada berbagai mesin POSIX lainnya di mana bash dikirimkan di berbagai lokasi, seperti /usr/xpg/bin/bash atau /usr/local/bin/bash .
Untuk menulis skrip bash portabel, oleh karena itu kita tidak dapat mengandalkan hard-coding lokasi bash program. POSIX sudah memiliki mekanisme untuk mengatasinya:PATH . Idenya adalah Anda menginstal program Anda di salah satu direktori yang ada di PATH dan sistem harus dapat menemukan program Anda saat Anda ingin menjalankannya dengan nama.
Sayangnya, Anda tidak bisa lakukan saja ini:
#!bash
Kernel tidak akan (beberapa mungkin) melakukan PATH mencarimu. Ada sebuah program yang dapat melakukan PATH mencari Anda, namanya env . Untungnya, hampir semua sistem memiliki env program terinstal di /usr/bin . Jadi kita mulai env menggunakan jalur hardcoded, yang kemudian menghasilkan PATH cari bash dan menjalankannya sehingga dapat menginterpretasikan skrip Anda:
#!/usr/bin/env bash
Pendekatan ini memiliki satu kelemahan:Menurut POSIX, hashbang dapat memiliki satu argumen . Dalam hal ini, kami menggunakan bash sebagai argumen untuk env program. Itu berarti kita tidak memiliki ruang tersisa untuk meneruskan argumen ke bash . Jadi tidak ada cara untuk mengonversi sesuatu seperti #!/bin/bash -exu untuk skema ini. Anda harus memasukkan set -exu setelah hashbang sebagai gantinya.
Pendekatan ini juga memiliki keunggulan lain:Beberapa sistem mungkin dikirimkan dengan /bin/bash , tetapi pengguna mungkin tidak menyukainya, mungkin menganggapnya bermasalah atau ketinggalan zaman, dan mungkin telah memasang bash miliknya sendiri di tempat lain. Hal ini sering terjadi pada OS X (Mac) di mana Apple mengirimkan /bin/bash yang kedaluwarsa dan pengguna menginstal /usr/local/bin/bash terbaru menggunakan sesuatu seperti Homebrew. Saat Anda menggunakan env pendekatan yang melakukan PATH pencarian, Anda mempertimbangkan preferensi pengguna dan menggunakan bash pilihannya daripada bash yang disertakan dengan sistemnya.
Untuk bourne shell:
sh myscript.sh
Untuk pesta:
bash myscript.sh