Re: Usr/bin/env

[Andreas Kusalananda Kähäri]

On Sat, Aug 14, 2021 at 09:47:20PM +0200, Thomas Paulsen wrote:
> 
> >/usr/bin/env
> see: 
> https://unix.stackexchange.com/questions/29608/why-is-it-better-to-use-usr-bin-env-name-instead-of-path-to-name-as-my
> 
> Excerpt: '
> Since using a logical path- /usr/bin/env to the interpreter in the she-bang 
> is the most extensible solution allowing the same script to execute 
> successfully on target hosts with different paths to the same interpreter, 
> we'll test it- using Python due to its' popularity- to see if it meets our 
> criteria.
> 
> '
> 
> 

Also note that the next answer down has nearly ten times the upvotes
and shows some of the potential issues with using /usr/bin/env in the
#!-line.  These are, using my own words:

1. You leave it up to the user to set their PATH in such a way that
   the *correct* interpreter is found.  Failure to set the correct
   directories in PATH (for example, in cron jobs) leads to issues with
   running your script.

2. You can't generally pass additional options to the interpreter.

3. There exists, or has existed, systems where the env utility lives
   elsewhere than in /usr/bin.


Personally, if I'm writing scripts that I'm distributing, e.g. as a
project or part of a project, I tend to let a configure script (GNU
auto-tooling) fill in the found bash or sh interpreter's path in the
#!-line.  This is not different from adjusting other things for a
particular host when installing software via the GNU auto-tools.


-- 
Andreas (Kusalananda) Kähäri
SciLifeLab, NBIS, ICM
Uppsala University, Sweden

.