Yes... but do not take that as a "cargo cult script shebang".
If you're a sysadmin writing a script for a company with 2k linux servers, that has a policy of "we only use linux version Foo X"... and we do not use other bash in the system than /bin/bash (no bash compiled by hand, no multiple versions of bash, etc)... then portability via "env" does not make sense.
If you have two laptops and a raspberry at home, with debian or arch, and you write a script for yourself... then portability via "env" does not make sense.
And last but not least... using env is slower.
See:
strace -fc /bin/bash -c ':'
Vs
strace -fc /usr/bin/env bash -c ':'
On my system, that's 92 syscalls and 3 errors, Vs 152 syscalls and 8 errors.
Just to start procesing.
Diferent levels of system bloat (environment, library paths, etc) can give different results than my example.
And as others said... if you're not using GNU/bash syntax and the script is really simple, the best for portbility is to go with /bin/sh.
strace -fc /bin/sh -c ':'
On my system 41 syscalls and 1 error... (and less RAM, CPU and pagefaults).
If you're not using associative arrays, array indexes, non POSIX builtin options, and other bash extensions... if the script is just to join a few commands and variables... it pays the effort to write it in simple sh, both, for portability and performance.
- Do I trust my code to run on a machine where /bin/bash doesn't work?
- Do I trust my users to have their PATH configured correctly?
IME a user misconfiguring ~/.bashrc is about seven million times more likely than some theoretical argument about "portability", or even the idea that running my code on some unspecified version of bash that a mac user accidentally downloaded while screwing up a Homebrew copy/paste command is preferable to using the factory default that everyone has.
- Do I respect people who have set up their PATH correctly (to prefer, by example, a newer /usr/local/bin/bash or $HOME/bin/bash than the standard /bin/bash)
Yes... but do not take that as a "cargo cult script shebang".
If you're a sysadmin writing a script for a company with 2k linux servers, that has a policy of "we only use linux version Foo X"... and we do not use other bash in the system than /bin/bash (no bash compiled by hand, no multiple versions of bash, etc)... then portability via "env" does not make sense.
If you have two laptops and a raspberry at home, with debian or arch, and you write a script for yourself... then portability via "env" does not make sense.
And last but not least... using env is slower.
See:
Vs On my system, that's 92 syscalls and 3 errors, Vs 152 syscalls and 8 errors.Just to start procesing.
Diferent levels of system bloat (environment, library paths, etc) can give different results than my example.
And as others said... if you're not using GNU/bash syntax and the script is really simple, the best for portbility is to go with /bin/sh.
On my system 41 syscalls and 1 error... (and less RAM, CPU and pagefaults).If you're not using associative arrays, array indexes, non POSIX builtin options, and other bash extensions... if the script is just to join a few commands and variables... it pays the effort to write it in simple sh, both, for portability and performance.