more rationale for not using #!/bin/bash? about pure-bash-bible HOT 31 CLOSED

• bash may not be in /bin.
• The user may not have /bin/bash as the first match for bash in their $PATH.

These are the only two reasons really. It's more about portability than anything else.

from pure-bash-bible.

This has a drawback. " env " must also be in " /usr/bin/ " otherwise it may not work.

This has become kind of a standard now, though. Systems like Termux and Haiku which don't have it there seem to have checks to emulate it.

from pure-bash-bible.

Do you mean /usr/bin/env?
I thought that " #!/bin/bash " also kind of a standard.

It's often used, but systems such as FreeBSD and OpenBSD have it in /usr/local/bin instead.

Only convincing people (to use /usr/bin/env bash) can take many years.
Reinstalling the program is faster,
even if he has to reinstall the half repository with the new bash location.

You don't need to make everyone use it in order for it to work. You could say that about a lot of things; I mean, this whole project is for pure Bash tricks, when many use external programs instead.

Also, lots of people already use it; it's not a new concept, nor Bash-specific. It's also used with Python, Perl, Ruby, etc.

It's worse when someone other doesn't stick to the standards and we need to fix his scripts.

What?

I think you can use for your own needs
#!/usr/bin/env bash
but it may not start correctly program from other location if you have
two versions of the same program with the same name but in other place and all paths are in
$PATH.

If you put another Bash higher in the PATH you clearly want it to be launched instead, no? I don't get what you mean by this.

For example, the default Bash's version in macOS is 3.2. Thus, many who use it would install a more recent version to /usr/local/bin or something, so it would be used instead. But if you use #!/bin/bash, it will still launch the outdated version, potentially breaking your script.

I would say it's the other way around: it's fine to use #!/bin/bash personally, because you can guarantee that it's there and you want it specifically. But otherwise, users in general would probably prefer #!/usr/bin/env bash.

You don't seem to really care about portability, though. It's old, so I don't know if you've changed your mindset since then, but you forcibly require /bin/bash in one of your projects, making it fail even if launched through bash fu or editing the shebang as you suggested if Bash isn't located there.

from pure-bash-bible.

#!/usr/bin/env is perfect for software distributed across operating systems and for use by various users. It's supported everywhere (see the list of operating systems neofetch supports) and nowadays, it "just works".

#!/bin/bash is fine for personal scripts, scripts intended for a single operating system (where /bin/bash exists) or for security focused scripts which would much rather skip the $PATH checks or the user configured bash installation.

This isn't really up for debate at all. There are pros and cons to both and there are clear reasons for why you'd use one over the other. Utilizing both of these methods covers every use case I can think of and I don't see how an alternative could be more portable, simpler, easier to use or more robust.

At the end of the day, if you want 100% guaranteed POSIX portability and compatibility, write your scripts in POSIX sh, use #!/bin/sh and stick to the POSIX specifications when using core utilities.

In my eyes, this is a "solved" problem.

from pure-bash-bible.

https://en.wikipedia.org/wiki/Shebang_(Unix)

1. " /usr/bin/env " can be used for " portability ",
   but writing

 # Wrong:
 #!/bin/bash

It won't find recognition in most security guides.
Paths should be written directly as is possible.
Because sometimes you can change the variables.

2. This has a drawback. " env " must also be in " /usr/bin/ " otherwise it may not work.
   And if any path is not in "$PATH" then env will not find the program.

3. I give an example which I know. ( I know, a poor example )

$ locate python | grep ^/usr/bin
/usr/bin/python
/usr/bin/python2
/usr/bin/python2.7
...
$ ls -l /usr/bin/python
lrwxrwxrwx 1 root root 7 Dec 21  2018 /usr/bin/python -> python2*

$ ls -l /usr/bin/python2
lrwxrwxrwx 1 root root 9 Dec 21  2018 /usr/bin/python2 -> python2.7*

I want to say that I can have several versions of the same program and by changing the link, I can redirect to the appropriate version of the program or to another location. And it's probably safer.

PS. please don't look at rwx permissions.
I don't know why it looks like this for links.
Happiness doesn't work that way.

from pure-bash-bible.

Sure, there are times when a direct path is preferred. Keep in mind that what I write in this guide is not absolute and you may have good reasons for doing task a differently.

I've added a note to the README in this location.

from pure-bash-bible.

Do you mean /usr/bin/env?
I thought that " #!/bin/bash " also kind of a standard.
The guide shows how to run script when the program is in a different place.

I'm guessing that someone knows little or has not come up with an idea run script like this
/own/path/to/bin/bash name_of_script
or just
bash name_of_script
which is used for convenienceand which use $PATH
or in file edit
#!/own/path/to/bin/bash
( And that's all allow run script for own needs. )

Or someone does not stick to the standard and came up with a brilliant idea
convince everyone to use
#!/usr/bin/env bash
which allow run
./script
without editing each new script from other linux distributions
or just without installing the program in a more correct place.
Only convincing people (to use /usr/bin/env bash) can take many years.
Reinstalling the program is faster,
even if he has to reinstall the half repository with the new bash location.
Moral:
It is better to stick to the standards than then think about how to fix it.
It's worse when someone other doesn't stick to the standards and we need to fix his scripts.

Or it was just an example from other program with a similar problem.

I think you can use for your own needs
#!/usr/bin/env bash
but it may not start correctly program from other location if you have
two versions of the same program with the same name but in other place and all paths are in $PATH.

from pure-bash-bible.

I know only Linux, I don't know BSD systems.
Do you know if they (BSD) use /usr/bin/ path ?

For Linux I know only:
Standards:

1. Linux Standard Base (LSB) http://refspecs.linuxfoundation.org/lsb.shtml
2. Filesystem Hierarchy Standard (FHS) http://refspecs.linuxfoundation.org/fhs.shtml
3. Link to whole list Standards http://refspecs.linuxfoundation.org/
4. Freedesktop Specifications (FS) https://www.freedesktop.org/wiki/Specifications/

Exist also Unix standard (Linux and BSD)
But it's probably paid ( it is not free )
And I can not check.

However
FHS http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#usrbinMostUserCommands

To make such scripts portable among different systems, it is advantageous to standardize the interpreter locations. The shell interpreter is already fixed in /bin by this specification, but interpreters for Perl, Python, Tcl and expect may be installed in various places. The locations specified here may be implemented as symbolic links to the physical location of the interpreters.

It seems to me a much smarter solution, than
edit and making all scripts more portable. For example when you want install app from Linux to BSD.
And it also looks more KISS.

Maybe I was received wrongly.
Maybe my English is poor.

I think you can use for your own needs

but I do not recommend using #!/usr/bin/env bash because it is more problematic.

from pure-bash-bible.

I know only Linux, I don't know BSD systems.
Do you know if they (BSD) use /usr/bin/ path ?

As far as I know, yes, but only for the base system, which Bash is not part of; all others go into /usr/local/bin.

However
FHS http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#usrbinMostUserCommands

To make such scripts portable among different systems, it is advantageous to standardize the interpreter locations. The shell interpreter is already fixed in /bin by this specification, but interpreters for Perl, Python, Tcl and expect may be installed in various places. The locations specified here may be implemented as symbolic links to the physical location of the interpreters.

Are you sure that it isn't talking about sh, not Bash? I'm completely for #!/bin/sh.

It seems to me a much smarter solution, than
edit and making all scripts more portable. For example when you want install app from Linux to BSD.

I mean, you don't have to edit anything if you just use #!/usr/bin/env bash in the first place. The smartest solution to me seems to be officially standardizing /usr/bin/env, as it also solves the others it mentioned and more. It's not their fault if the authors didn't want to make their script portable; it's not like `env' is a new thing that they will have to adopt.

from pure-bash-bible.

Are you sure that it isn't talking about sh, not Bash?

FHS mentions solution for all programs.
However as I mentioned, I don't know BSD systems, if you feel need, you can check and write us what have you seen.

from pure-bash-bible.

Are you sure that it isn't talking about sh, not Bash?

FHS mentions solution for all programs.
However as I mentioned, I don't know BSD systems, if you feel need, you can check and write us what have you seen.

Again, I'm pretty sure that programs outside of the base installation (Bash isn't, but env is, of course) are in /usr/local/bin.

EDIT: Also, I was talking about this part of the quote:

The shell interpreter is already fixed in /bin by this specification,

It seems to be talking about sh. If so, it seems that it's saying that Bash should be in /usr/bin, no?

from pure-bash-bible.

It doesn't matter for me, if it's not there, you can always create a symbolic link to the right program in system, as mentioned in the guide.

from pure-bash-bible.

I am guessing that there are no problems with sh.
I have sh in /bin/sh (Linux)

$ ls -l  /bin/sh
lrwxrwxrwx 1 root root 4 Dec 21  2018 /bin/sh -> bash*

For the sensor to discover the operating system, the /bin/sh script must be configured as a default shell.

https://www.ibm.com/support/knowledgecenter/SSPLFC_7.3.0/com.ibm.taddm.doc_7.3/SensorGuideRef/r_cmdb_sensor_freebsd.html

But I don't know if this is also a standard for all BSDs.

from pure-bash-bible.

It doesn't matter for me, if it's not there, you can always create a symbolic link to the right program in system, as mentioned in the guide.

That is not a good solution; I'm assuming that the guide meant that for packagers.

I am guessing that there are no problems with sh.

No, there aren't, as I mentioned earlier. /bin/sh is available in pretty much every system but Windows.

from pure-bash-bible.

I do not know what you want to achieve.
If you are unsure of the effectiveness of the links you can see this
http://sgeos.github.io/freebsd/bash/2016/02/20/bin-bash-on-freebsd.html
If you want to use in scripts #!/bin/sh
I can not help you, I don't use it and I don't understand why you can't use it.
I do not know any guide sh. Someone once paid me attention only to syntax
to make scripts more portable for sh
But I don't remember these rules.

from pure-bash-bible.

...I think you'll find #!/usr/bin/env bash the most universal
way to find the bash binary on different, OS.

Some history may be helpful to understand the situation.
Bash is an extension from the Bourne shell which has fewer
string manipulations and similar features but has been around
quite a bit longer. It remains on OS that have it because it
continues to do the job for its intended purpose, bootstrap
and "UNIX Programming Environment" tasks. I've only seen
it installed as /bin/sh, today that is often a symlink to bash,
ash or whatever is the preferred bootstrap shell on systems
that don't provide Bourne (the license predates GNU).

The UNIX/BSD systems, etc, that don't use bash as default
(for their own good reason not related to this issue) but
have it available as a package, will typically install as
/usr/local/bin/bash or /usr/pkg/bin/bash, but /usr/bin/env bash
can be expected to work if bash is available.

It is worth noting, the rather complicated invocation paragraph
in the bash man page has more to do with supporting all of
the predecessors simultaneously, than any particularly
good way to read run control and local configuration files.
I discussed more details in a thread about identifying a
reliable shell invocation to bootstrap a python version
selector: pyenv/pyenv#1347 pyenv/pyenv#1359

from pure-bash-bible.

Reopening this as it's a good discussion on the topic.

from pure-bash-bible.

@georgalis

... most universal way to find ...

I don't want to write too much but some things need explanation and are not directly related to the topic.

• Is that most believe in something does not mean that it is correct.
  (I hope my English is good because this syntax ("it is right.") looks incorrect for me, so I used "correct")
  Therefore, it should not be mentioned as a reason.
• I believe that people need guidance. Because new people are still born or they come to something and they need knowledge for not to make mistakes.
• We are all imperfect creatures. I mean by , that we never know when we will be wrong / we will break.
• Our goal is continuous development and improvement of ourselves.

For now, I see only one your problem.

... I've supported many shells (bash, bourne, zsh, ksh, ash, etc) on different OS (Linux, BSD, Darwin) at different sites. I've also created a tool set of command line functions and aliases. Getting your shell all setup with tuned and bug free preferences can take forever and a week and it's the last thing you want to fix when you've got other work to do. ...

Maybe symbolic links don't cure all things, I can't check it.
But workarounds should be temporary and not permanent.
Especially if they are not perfect.
I understand the frustrations but most of us should strive for the perfect order if it is possible.
That is to the standard if it is possible to avoid problems, for example yours.
As a solution, I see the creation of a package that contains missing catalogs and symbolic links.
Until adaptation of most systems to a common standard.
We should report such problems to our system distribution developers if such a problem exists
This should solve your problem with manually configuring each system.
I know from experience that changes are not always possible. Because some developers do not care about other / foreign standards. But it's worth trying to ask.

Probably a similar scheme (packgage with missing dirs and links) was used in linux distributions which use repositories from various Linux distributions, but I have never had time to get to know them more, so I can't give guarantee.

Not related to the topic also.
There have been many problems with the su command recently in the Debian distribution.
I want to say that variables can be in several different places. (Environment Variables)

$ locate bashrc
/etc/bashrc
/home/user_name/.bashrc
...

And I know from own experience that also in programs, for example in the login manager.
Probably the most universal for all users is the file /etc/bashrc
https://wiki.gentoo.org/wiki//etc/portage/bashrc
This is an example that it can also be problematic when users switch to something other and suddenly there is no needed variable, because it occurs only locally.
Therefore the most important environmental variables should be in one place.
However, I understand that some developers remove variables to prohibit the use of programs,
that is, each case should be considered individually.

from pure-bash-bible.

I do not know what you want to achieve.
If you are unsure of the effectiveness of the links you can see this
http://sgeos.github.io/freebsd/bash/2016/02/20/bin-bash-on-freebsd.html

It works, yes. But you're suggesting every BSD user that wants to run Bash to use a hack messing with their system directory instead of simply using /usr/bin/env. You're also assuming that they have root access in the first place.

As a solution, I see the creation of a package that contains missing catalogs and symbolic links.
Until adaptation of most systems to a common standard.

The BSDs will not place it there. They have been around for a long time; why do you think they'll change it now?

I know from experience that changes are not always possible. Because some developers do not care about other / foreign standards.

The foreign standard is to use /usr/bin/env; you are the one who isn't changing to it. You can't expect these system developers to bend their rules for one utility they don't even like to save scripting developers from adding a few more characters to their shebang.

And what of macOS? It already has a /bin/bash but it's severely outdated, at version 3.2. Many scripts require a more recent version.

And what of other interpreters? Do you suggest for users to make links for Python, Perl, Ruby, Lua, Tcl, etc., too?

Also, I want to stress again that using env is not a new concept that isn't adopted yet and is used in pretty much every Bash script that wants to be portable. This includes scripts by big organizations such as Microsoft, Google, NSA, NPM, etc. Most of the scripts that are still using #!/bin/bash are small, personal ones, as any script with it that gets popular will get a pull request to change it.

The main problem with using env is that the behavior of multiple arguments in shebangs isn't specified by POSIX. Therefore, you cannot portably add options when using env. However, in Bash you can just use set in the line after; this mostly affects other interpreters such as awk, which requires the -f argument to interpret the file.

If you want to use in scripts #!/bin/sh
I can not help you, I don't use it and I don't understand why you can't use it.
I do not know any guide sh. Someone once paid me attention only to syntax
to make scripts more portable for sh
But I don't remember these rules.

You can use it, and you should if possible, but it has less features than Bash. You may want to check out the pure sh bible.

from pure-bash-bible.

The BSDs will not place it there. They have been around for a long time; why do you think they'll change it now?

Do you mean transferring the bash to /usr/bin?
The world is changing, maybe they will say it's worth it.
At least for now. Until someone finds a better solution.

I will give a little different example.
When I build a package for the system, I use special variables where the package should be installed.
I am thinking of compiled packages, not scripts.

$ rpm -E %_bindir
/usr/bin

So I realize that every system distribution may want to install the program in its / own location.
And this should be respected.
However, standardization sometimes brings more benefits to everyone. But I do not press.
And something else. We rarely use variables to run the program.

• we usually give the path to the program

$ strace -e open bash
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
open("/lib/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
open("/lib/i686/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/dev/tty", O_RDWR|O_NONBLOCK|O_LARGEFILE) = 3
open("/usr/share/locale/locale-archive", O_RDONLY|O_LARGEFILE|O_CLOEXEC) = 3
open("/proc/meminfo", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/gconv/gconv-modules.cache", O_RDONLY) = 3
open("/home/user/Desktop/Praca/TEST/TEST3/bash", O_RDONLY|O_LARGEFILE) = 3
Succes
+++ exited with 0 +++

And when I noticed it, I know that it is problematic for developers, because they have to write an installation script that links all installed files.
But I have never looked for a solution because it is not my plot.
( If you noticed also /TEST/TEST3/bash don't panic, I did it on purpose )

Returning to env.
https://en.wikipedia.org/wiki/Env
I guess env has more than one use / applications and I can't forbid anyone to use it.
I just wanted to point out the problems with using this.
The main problem are variables.
When we want to run a program, we should give the full path to the program or
use variables that cannot be changed by the program itself or by the ordinary user.

I don't understand one more thing.

... such as FreeBSD and OpenBSD have it in /usr/local/bin instead.

Where from FHS http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#usrlocalLocalHierarchy

The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated.

BSD systems use other FHS?

from pure-bash-bible.

The BSDs will not place it there. They have been around for a long time; why do you think they'll change it now?

Do you mean transferring the bash to /usr/bin?
The world is changing, maybe they will say it's worth it.
At least for now. Until someone finds a better solution.

? Even if they do, most scripts currently use /bin/bash, not /usr/bin/bash.

And again, they won't. /usr/bin is strictly for the base installation, and no way are they going to add Bash to it. They are very strict about what goes into it and even removed Perl fairly recently.

Also, I would say that there is a better solution: using /usr/bin/env

Returning to env.
https://en.wikipedia.org/wiki/Env
I guess env has more than one use / applications and I can't forbid anyone to use it.
I just wanted to point out the problems with using this.
The main problem are variables.
When we want to run a program, we should give the full path to the program or
use variables that cannot be changed by the program itself or by the ordinary user.

What? When you want to use ls, do you always type out /usr/bin/ls? Also, programs and users are free to change any variable in its own environment. I don't get what's you're trying to say.

I don't understand one more thing.

... such as FreeBSD and OpenBSD have it in /usr/local/bin instead.

Where from FHS http://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#usrlocalLocalHierarchy

The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated.

BSD systems use other FHS?

FHS is a Linux standard, as far as I know; I mean, the URL is from linuxfoundation.org.

from pure-bash-bible.

@Crestwave

When you want to use ls, do you always type out /usr/bin/ls?

Now you see, I've written scripts all my life in a dangerous way, and I didn't realize it. 😄
I suggest that someone wiser must find a better solution.
And for now you can choose what you want.

from pure-bash-bible.

@Crestwave

And again, they won't. /usr/bin is strictly for the base installation, and no way are they going to add Bash to it. They are very strict about what goes into it and even removed Perl fairly recently.

I also mentioned the possibility of building a package (separate) for program(s) portability. Because not everyone will want to have unnecessary additional directories and links. You will not force anyone to use env either.
So both of these ideas ( with dirs, links and env ) are not perfect.

from pure-bash-bible.

@Crestwave
Curiosity: It is possible to avoid variables from user settings in the $PATH / script.

For example, I created "test" script with line echo $PATH
The examples are not perfect.

This running script shows my modified $PATH variable.

$ /bin/bash  test
/home/user/Desktop/Praca/TEST/TEST3:/bin:/usr/bin:/sbin:/usr/sbin:/usr/games:/usr/lib/qt4/bin:/usr/lib/qt5/bin:/home/user/bin:/usr/lib/qt5/bin

Bash with option login.
But this should be checked more carefully https://wiki-dev.bash-hackers.org/

$ /bin/bash -l test
/bin:/usr/bin:/sbin:/usr/sbin:/usr/games:/usr/lib/qt4/bin:/usr/lib/qt5/bin:/home/user/bin

Example with env

$ /usr/bin/env  bash test
We run false bash before run script.

Env with option invoke.
Missing a few paths and additionally is a dot at the end.
(Maybe there is a way to improve the command, I don't know)

$ /usr/bin/env -i bash test
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.

Edited
About "bash -l"
I thought it worked perfectly. Does not work perfectly.
I'm happy except one. In the $PATH is name /home which I found
( # grep -ri "PATH=" /etc | grep 'bash|profile' )
in /etc/skel/.bash_profile:PATH=$PATH:$HOME/bin
I checked again by deleting above line from ~/.bash_profile and it looks better after rebooting.
I know, exist option "--noprofile" for bash but it doesn't work for me, maybe I have something too old or it's just a bug in my linux distribution.
( I know about chattr +i /path/to/file , but is easier use env )

from pure-bash-bible.

FWIW, /bin/bash shebangs won't work on NixOS.

from pure-bash-bible.

@abathur
I read https://en.wikipedia.org/wiki/NixOS

... NixOS doesn't follow the Filesystem Hierarchy Standard. The only exceptions are a symlink /bin/sh to the version of bash ...

So I'm guessing you can only use scripts compatible with sh.

I'm guessing if you want run script only compatible with
bash, ash, dash, ksh, pdksh, mksh, zsh or other ...
You can create a link in /bin/app_name
Or keep the correct version of app name in $PATH for use /usr/bin/env
... if path "/usr/bin/env" can be used.

from pure-bash-bible.

/usr/bin/env is preferred.

They would also prefer to get rid of /bin/sh as well, but there's a long-running unresolved issue ( NixOS/nixpkgs#1424, among others) with glibc depending on it.

from pure-bash-bible.

@Crestwave's point is the most valid (and painful). We support a large set of scripts, and can't go above bash 3.2 features because MacOS.

AFAIK, Homebrew installs a newer version of bash into a directory which precedes /bin on the PATH, so the /usr/bin/env is an essential trick for people using modern bash on this technologically retarded system.

from pure-bash-bible.

Good lord the comments in this thread. Should make it an interview question...

tl;DR - Google et all can use env all they want, they're an exception in that they have full control over their environment. To use them as an example of why we all should follow is ... stupid.

For the record:

$  { cd /bin ; file * |grep script | while read a b ; do head -1  ${a/:/}  ; done  | grep -v ELF | sort | uniq -c | sort -n |grep -a env ; }
      1 #!/bin/env python
      1 #! /usr/bin/env python
      1 #!/usr/bin/env python2
      1 #!/usr/bin/env python2.7
      1 #!/usr/bin/env sh
      1 #!/usr/bin/env texlua
      2 #!/usr/bin/env lua
      2 #!/usr/bin/env node
      3 #!/usr/bin/env bash
      3 #!/usr/bin/env perl
      5 #!/usr/bin/env python
      6 #!/usr/bin/env /usr/bin/python

To say the use of env is universal, is equally stupid. Fact that 6 of those are python should say where this FUD comes from.

Use it in your own personal scripts, stay the hell away from system.
Thank you.

from pure-bash-bible.

Good lord the comments in this thread. Should make it an interview question...

tl;DR - Google et all can use env all they want, they're an exception in that they have full control over their environment. To use them as an example of why we all should follow is ... stupid.

This is a bit dramatic in the context of choices marked Right and Less Right, and prefaced with NOTE: There are times when one may have a good reason for using #!/bin/bash or another direct path to the binary.

For the record:
...
To say the use of env is universal, is equally stupid.

I'm not sure why you think the contents of /bin have any bearing on a portability recommendation. The overwhelming majority of all bash scripts ever written will not see the inside of /bin. I have 0 bash scripts in /bin on either system in front of me.

this FUD

🙄

Use it in your own personal scripts, stay the hell away from system.

Neither of these is the point. Use whatever you want in your personal scripts. If you're writing for an audience, use /usr/bin/env. Nothing in here says to go change the shebang of every script on your system.

If PATH manipulation affecting which bash interprets readonly scripts is this far up your list of concerns, I assume you're already doing something like auditing these scripts and any subsequent scripts/binaries invoked to ensure all executables are invoked using the absolute paths of a verified readonly executable, or at least patching them to use fixed PATHs?

from pure-bash-bible.

I'm not sure why you think the contents of /bin have any bearing on a portability recommendation.

Because there's' nothing "less right" about it. Why are you implying otherwise?

Neither of these is the point. Use whatever you want in your personal scripts. If you're writing for an audience, use /usr/bin/env.

You have that backward and fail to understand why.

Nothing in here says to go change the shebang of every script on your system.

I agree, any competent admin won't. You're implying env is better, stupid people will follow this advice, as indicated above.

If PATH manipulation affecting which bash interprets readonly scripts is this far up your list of concerns,

I don't know what that even means... env uses the PATH... by design.

from pure-bash-bible.