#! /usr/bin/env considered harmful - General Shell Scripting
(14-09-2016, 08:59 PM)pranomostro Wrote: > Not the right interpreter is found

Generally we then have to ask for the better alternatives. If we specify a path, we can never be sure it works (because none of this shit is standartized, except the location of /usr/bin/env).

Some path are standardized by POSIX, like /bin/sh. env(1) location is not defined by POSIX. All it does is that it will run the 'utility' using the current environment, which is supposed to has the $PATH variable set correctly. One could technically just implement the shebang to search 'utility' in the PATH, which would allow things as "#!sh".

(14-09-2016, 08:59 PM)pranomostro Wrote: > No dependencies or modules

I can't say anything about that since the most things I use scripting for is either rc or lua, where I don't happen to need modules or dynamically linking libraries. Someone smarter than me comment on this please.

I'm not especially smarter than you are, but as far as I understand this point, it present corner cases where the same 'utility' appear multiple times in the PATH, at multiple locations. That's the same as you 3rd point.

(14-09-2016, 08:59 PM)pranomostro Wrote: > no flags

This is really stupid. This is one of the stupid unix limitatians I talked about, things that don't make any sense today but are still included.
But it applies to other shebangs as well, so I would say fuck that.

This is, again, implementation specific. And while it MIGHT be the case, it has never been actually experienced (see http://www.in-ulm.de/~mascheck/various/shebang/). What's true though, is that the shebang line is limited, and this limitation is (again!) implementation specific. I've personally been using "#!/bin/sed -f" or "#!/bin/sh -ex" happily for quite some times now.

(14-09-2016, 08:59 PM)pranomostro Wrote: > wrong configuration of $PATH

Then your user is a moron and it is his own fault. $PATH should never be changed, only appended to.

The solutions given are both bloated and unportable. env seems like the cleaner solution to me. I don't like using tho whole path since people thought it would be a good idea to put binaries into different directories. Ugh.

The exact problem mentionned is "The fifth and worst problem is that your script is at the mercy of the user’s environment configuration.".

THAT IS THE FUCKING POINT OF THE env(1) UTILITY! Of course it will use the environment of the user BECAUSE THAT'S FUCKING WHAT YOU'RE ASKING FOR. "#!/usr/bin/env bash" means "run 'bash' within the current environment. So it's freaking stupid to discuss this point as it would be like complaining about planes not touching the ground all the time.

Regarding this whole topic, the shebang is a nifty feature provided by some kernels to hack around the fact that some executables are NOT executable by a machine. You shouldn't expect much about it, but you can have enough confidence in it to use it (It's kind of like relying on bash(1) to be installed everywhere in the end).

By nature, the shebang is not portable, for the simple reason that it's not standardized:

http://pubs.opengroup.org/onlinepubs/969...hap02.html Wrote:If the first line of a file of shell commands starts with the characters "#!", the results are unspecified.
Heh, I like using something like

    python - <<<CODE  
        import foo
        print('This will work')


My use of python is generally very limited, though. You can always specify version this way, as you're literally passing a heredoc to the python interpreter; you can call whichever interpreter in your path you require, or /usr/bin/python3.4 if you so desire.

edit - formatting is messed up, heh.

Members  |  Stats  |  Night Mode