Jika skrip shell mulai dengan #!/bin/bash, mereka akan selalu dijalankan dengan bashdari /bin. Jika mereka Namun mulai dengan #!/usr/bin/env bash, mereka akan mencari bashdi $PATHdan kemudian mulai dengan yang pertama mereka dapat menemukan.
Mengapa ini berguna? Asumsikan Anda ingin menjalankan bashskrip, yang memerlukan bash 4.x atau lebih baru, namun sistem Anda hanya memiliki bash3.x diinstal dan saat ini distribusi Anda tidak menawarkan versi yang lebih baru atau Anda bukan administrator dan tidak dapat mengubah apa yang diinstal pada sistem itu .
Tentu saja, Anda dapat mengunduh kode sumber bash dan membangun bash Anda sendiri dari awal, ~/binmisalnya sebagai contoh. Dan Anda juga dapat memodifikasi $PATHvariabel Anda di .bash_profilefile Anda untuk dimasukkan ~/binsebagai entri pertama ( PATH=$HOME/bin:$PATHkarena ~tidak akan diperluas dalam $PATH). Jika sekarang Anda menelepon bash, shell pertama-tama akan mencarinya secara $PATHberurutan, jadi itu dimulai dengan ~/bin, di mana ia akan menemukan bash. Hal yang sama terjadi jika skrip mencari bashmenggunakan #!/usr/bin/env bash, jadi skrip ini sekarang akan bekerja pada sistem Anda menggunakan custom bashbuild Anda.
Salah satu kelemahannya adalah, hal ini dapat menyebabkan perilaku yang tidak terduga, misalnya skrip yang sama pada mesin yang sama dapat berjalan dengan penerjemah berbeda untuk lingkungan yang berbeda atau pengguna dengan jalur pencarian yang berbeda, menyebabkan semua jenis sakit kepala.
Kelemahan terbesar envadalah bahwa beberapa sistem hanya akan mengizinkan satu argumen, jadi Anda tidak dapat melakukan ini #!/usr/bin/env <interpreter> <arg>, karena sistem akan melihat <interpreter> <arg>sebagai satu argumen (mereka akan memperlakukannya seolah-olah ungkapan itu dikutip) dan dengan demikian envakan mencari nama juru bahasa <interpreter> <arg>. Perhatikan bahwa ini bukan masalah envperintah itu sendiri, yang selalu memungkinkan beberapa parameter dilewati tetapi dengan parser shebang dari sistem yang mem-parsing baris ini sebelum bahkan memanggil env. Sementara ini telah diperbaiki pada sebagian besar sistem tetapi jika skrip Anda ingin menjadi sangat portabel, Anda tidak dapat mengandalkan bahwa ini telah diperbaiki pada sistem yang akan Anda jalankan.
Ia bahkan dapat memiliki implikasi keamanan, misalnya jika sudotidak dikonfigurasi untuk membersihkan lingkungan atau $PATHdikeluarkan dari pembersihan. Biarkan saya menunjukkan ini:
Biasanya /binadalah tempat yang terlindungi dengan baik, hanya rootdapat mengubah apa pun di sana. Direktori rumah Anda tidak, bagaimanapun, program apa pun yang Anda jalankan dapat membuat perubahan padanya. Itu berarti kode jahat dapat menempatkan palsu bashke beberapa direktori tersembunyi, memodifikasi Anda .bash_profileuntuk memasukkan direktori itu di Anda $PATH, sehingga semua skrip yang menggunakan #!/usr/bin/env bashakhirnya akan berjalan dengan palsu itu bash. Jika sudoterus $PATH, Anda dalam masalah besar.
Misalnya, pertimbangkan alat membuat file ~/.evil/bashdengan konten berikut:
#!/bin/bash
if [ $EUID -eq 0 ]; then
echo "All your base are belong to us..."
# We are root - do whatever you want to do
fi
/bin/bash "$@"
Mari kita membuat skrip sederhana sample.sh:
#!/usr/bin/env bash
echo "Hello World"
Bukti konsep (pada sistem tempat sudomenyimpan $PATH):
$ ./sample.sh
Hello World
$ sudo ./sample.sh
Hello World
$ export PATH="$HOME/.evil:$PATH"
$ ./sample.sh
Hello World
$ sudo ./sample.sh
All your base are belong to us...
Hello World
Biasanya semua shell klasik harus ditempatkan di /bindan jika Anda tidak ingin menempatkannya di sana untuk alasan apa pun, itu benar-benar bukan masalah untuk menempatkan symlink di /binyang menunjuk ke lokasi mereka yang sebenarnya (atau mungkin /binitu sendiri adalah symlink), jadi Saya akan selalu pergi dengan #!/bin/shdan #!/bin/bash. Ada terlalu banyak yang akan rusak jika ini tidak berfungsi lagi. Bukan berarti POSIX akan membutuhkan posisi ini (POSIX tidak membakukan nama jalur dan dengan demikian bahkan tidak menstandardisasi fitur shebang sama sekali) tetapi mereka sangat umum, bahwa bahkan jika suatu sistem tidak menawarkan /bin/sh, mungkin masih akan mengerti #!/bin/shdan tahu apa yang harus dilakukan dengannya dan mungkin hanya untuk kompatibilitas dengan kode yang ada.
Tetapi untuk penerjemah yang lebih modern, non standar, opsional seperti Perl, PHP, Python, atau Ruby, itu tidak benar-benar ditentukan di mana pun di mana mereka seharusnya berada. Mereka mungkin dalam /usr/bintetapi mereka mungkin juga berada di /usr/local/binatau di cabang hirarki yang sama sekali berbeda ( /opt/..., /Applications/..., dll). Itu sebabnya ini sering menggunakan #!/usr/bin/env xxxsintaks shebang.