Shell Programming and Scripting

Hi.

In thread Date Format Problem , Aia and I were discussing the usefulness of using #!/usr/bin/env bash (or ksh, or perl, or ...) as the shebang line. The exchange was good, but it was getting beyond the scope or the thread, so I decided to continue it here.

My preference is in favor of using it, while Aia wrote:
and

My reply to this is that in that same Wikipedia link, we see:
The exceptions noted in that Wikipedia article are:

Code:

There are still some portability issues with OpenServer 5.0.6 and Unicos 9.0.2 which have only /bin/env and no /usr/bin/env.

To which I say, if someone is porting to such earlier SCO or Cray OSs (or even to current implementations), they probably will have many more troubles than just the shebang line. Researchers don't usually run just shell scripts on Cray, etc. machines, they run very large, complex codes. The number of people using such machines are far in the minority compared to the other systems I mentioned in an earlier post.

(If it has been noted that I am from Minnesota, one might speculate that I have some connection with Unicos on Cray computers. Indeed I worked at the University of Minnesota and the associated Minnesota Supercomputer Center for about 25 years. We handled really big iron. If memory serves, when I left MSC, we had 3 Crays, an ETA-10, a Thinking Machines CM-2 (32K single-bit processors, ganged together to 1000 processors, SIMD), a TMC CM-5 (MIMD), a pair of 6-CPU IBM 3090s t(ied together through some very large memory accessory), and probably some other gear I have forgotten.

I live now in the suburbs, but even so, I live within walking distance to at least 5 colleagues who worked at Cray or MSC or both, including one who is a co-author of O'Reilly's bash Cookbook, from where I got the env shebang idea. It is worth noting that in that book one can find:
)

In summary, my conclusion is that #!/usr/bin/env is a very good solution to the problem of portability among the many environments that I often encounter, but to each their own.

Best wishes ... cheers, drl

Hi drl,

The topic of using env as a _silver bullet_ for portability in the Unices world has been discussed extensively on many forums and a quick search on the Net will produce many of those conversations.

Your experience, certainly, will contribute to how strongly you feel about a particular topic. However, portability is an elusive concept, as much as we would like to believe not so. The classic _it has worked for me for so many years_ or _I have never had a problem with it_ does not produce an assurance of portability, neither. And since this could be a call to _holy war_ for many, I would like to leave it there, on my part.

My original objective was to bring awareness that by using env you might be trading a _minor_ inconvenience (merely the need to know what systems you are coding for) for a whole new set of issues.

Thank you for including my post.

On many systems, #!/usr/bin/env utility will work for many common cases.

On systems that support multiple programming environments (like Solaris systems that use $PATH to choose between SVID3, XGP3, XPG4, XPG5, XPG6, old BSD, etc. environments), something like #!/usr/bin/env cmd where cmd is sh, awk, grep, sed, or any other utility that has different versions depending on the environment chosen) might or might not give you what you want depending on how PATH is set by the user invoking your script.

Since I worked at Sun for more than twenty years, I almost never use #!/usr/bin/env. And, I would never use that in any script that I would expect to ever be run on a Solaris system to get access to any utility that uses internationalized regular expressions.

Note also that I frequently see people posting scripts that use:

Code:

#!/usr/bin/env utility arg1 arg2 ...

or:

Code:

#! /usr/bin/env utility arg1 arg2 ...

but on some systems (at least in the late 1980's and early 1990's when the first version of the POSIX utilities standard was being developed) everything following the #! is treated as the name of the interpreter to be invoked. On those systems (if any still exist):

Code:

#!/usr/bin/env bash

will fail unless there is a utility named env<space>bash in /usr/bin. And, I'm pretty sure that there are still systems that will accept an interpreter name and one argument to it (as in the above invocation of bash), but won't accept more than one argument, such as in:

Code:

#!/usr/bin/env bash -xv

Why should a missing /bin/bash be more likely than a missing /usr/bin/env?
Well, it has been, for some time, 20 years ago, when bash was new. When the Internet was unknown by the public.
Today a shell can and must be assumed in /bin, only this eliminates surprises (=risks) of a manipulated PATH.
Your OS has perl only in /usr/bin? Open a bug with your vendor to also support /bin/perl! Even better: have the vendor link /bin with /usr/bin!

Hi.

Of the few discussions I have read, I like the one at shell script - Why is it better to use "#!/usr/bin/env NAME" instead of "#!/path/to/NAME" as my shebang? - Unix & Linux Stack Exchange

The main response leans towards the view of Aia and perhaps that of Don Cragun, mentioning the drawbacks. The follow-on responses there (including some from familiar names) illustrate that *nix provides the choice.

Whichever one prefers depends on the goal. As I have said, for me it's portability. I don't have similarly named codes on my systems. I don't have my ~/bin before the system directories. My PATH and root's PATH are the same respectively as possible on systems (Solaris an exception for /opt).

When I have a code that is a work-alike, either I name it differently, or I call it my-code, like my-tac, or my-uniq (too-limited a design for uniq, simple but not flexible enough for me). Currently I have about 40 of those, but for solutions that I provide to others I'm more likely to use standard commands.

The Linux distribution that I use most frequently is GNU/Debian. They seem to often use a scheme for numbering similar interpretors. So python -> python2.7, python3 -> python3.4:

Code:

$ version =o python python2.7
OS, ker|rel, machine: Linux, 3.16.0-4-amd64, x86_64
Distribution        : Debian 8.4 (jessie) 
Python 2.7.9
python2.7 Python 2.7.9

Don's comments reminds me of discussions I had with Sun. I really liked their hardware, and their man pages were very good because they often included examples, but otherwise Sun seemed very resistant to incorporate new features that users wanted or needed. That has changed a bit recently. One can use GNU utilities on (recent) Solaris systems:

Code:

$ version =o patch
OS, ker|rel, machine: SunOS, 5.11, i86pc
Distribution        : Solaris 11.3 X86
patch GNU patch 2.7.5

I'm not so much interested in the same as I am in the best.

Thanks to everyone for their comments ... cheers, drl