Hi, Aia.
Quote:
Nothing bits knowing the targets you are coding for. env can have the same problem that you are trying to solve, the binary could be in different location in different OSes. Also, it increases the risk of selecting the wrong interpreter, since it looks in each directory in the path, choosing the first one that it finds.
Thanks for your interesting reply. It's always good to have a different perspective on issues.
Are you saying that the
env binary may be in a directory different from
/usr/bin? If so, do you have an example?
Our experiences seem to differ. I use AIX, RHEL (CentOS), Antergos, AntiX, {Open,Free,Net}BSD, Haiku, HP-UX, Crux, Fedora, NixOS, Elementary, FreeNAS, Ubuntu, Debian, OSX, MiNT, PCBSD, Slackware, Solaris, SuSE, and Cygwin.
In the posts here and on other forums, I often present an entire script with results. If you look at them, I try to be in the same environment as the questioner. In every case that I can think of, the
env approach has worked successfully.
It may have failed on an infrequently used OS, I just don't recall it.
For my purposes, the ease of portability beats the likelihood that I find something wrong. I have more than 1000 scripts, and to use a number of those on different platforms that might require changes would be irritating. However, that's why I also suggested
fixin, but that would not solve the problem of same-named codes in different places.
As for interpreters of the same name being in different directories, that seems to me like a bad configuration idea, and an accident waiting to happen. If I encountered a situation like that, I'd try to improve the situation, to remove the risk, and, if not, try to remove myself.
I have had different versions of things, but I named them differently, e.g bash vs bash2 vs bash3 vs bash4, etc. And that was only a stop-gap until the old ones were removed after sufficient time of notice.
Best wishes ... cheers, drl
