Hacker News Reader

Comment by masklinn | Hacker News Reader

> Specify the /usr/local Prefix in Scripts

> When writing scripts, specify the full path to the executable you’ve installed in the first line of the script.

No. Don't do that. Bad. Even for maintenance and admin scripts, that makes them severely less portable and harder to keep in sync across machines for various reasons. Your path is setup correctly, just use that: there are very few reasons for your shebang lines to be anything other than:

    #!/usr/bin/env $executable "$options"

This will make the shebang work using the normal rules of path-resolution, and means path-override tools and methods (e.g. python virtual environments, or `PATH=$somedirectory ./script`) will work correctly.

edit: I am told not all versions of shebang/`env` support passing options to the $executable, and most notably it doesn't work on Linux. So don't do that, and i won't in the future. Still, $executable is usually sufficient

View on HN

While I agree about the use of /usr/bin/env, you should be aware that some systems will perform only one word split on the shebang line. That means that if you use env, you can't pass any options to the $executable.

You can try it if you want, save this into an executable file (test.awk):

    #!/usr/bin/env awk -f
    { print $2 }

Then run:

    echo "Hello world again" | ./test.awk

I get the following:

    /usr/bin/env: awk -f: No such file or directory

> I get the following:

Damn. I get "world" (OSX, zsh, BSD env)

So I supposed you can't pass options to `env` either (e.g. `-i`, or ENVVAR overrides?)

This is a kernel issue, it has nothing to do with userspace tools. For example, the Linux code responsible for parsing shebangs is here:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stabl...

Interesting, thanks for the info. I wouldn't have thought it so low in the architecture.

Linux doesn't support options, unfortunately. The executable path /usr/bin/env is parsed, then the remainder of the line is used as a single argument, spaces and all:

  $ cat x.py
  #!/usr/bin/env python -i

  $ ./x.py 
  /usr/bin/env: python -i: No such file or directory

+1.

At a previous job, I spent hours rebuilding a ruby gem where someone had carelessly hard-coded "#!/usr/local/bin/ruby" into all of their executables.

Even if it looks like it works, don't do it! Stick to "#!/usr/bin/env ruby" for maximum compatibility, please.

Was this a publicly available gem? Did you pass your feedback upstream?

It was an obsolete gem that our obsolete code still depended on. There's reasons I don't work for that company anymore :)

Coming from a c and python perspective, I'm amazed that you even can specify which ruby to run it with. Either its a compiled binary, or you call the interpreter with the code object as an argument. What is the design impetus for mixing scripting and executable styles this way?

Shebangs (#!) have been around for quite a long time. It's actually really handy to be able to write a script that you can execute as a command. See https://en.wikipedia.org/wiki/Shebang_(Unix)

> Coming from a c and python perspective, I'm amazed that you even can specify which ruby to run it with.

Erm... you can do the exact same thing in Python, you know...

It's a little more complicated than that. Using /usr/bin/env in your shebang is effectively a way to say "I don't care which executable you run this with". If the executable doesn't actually matter, that's fine - bash scripts probably don't care whether bash is /bin/bash or /usr/bin/bash, so it makes sense to just use whichever is in the path.

Once you start getting into Python/Ruby/Perl/etc scripts, the executable actually does matter and relying on env can make your script fragile with respect to path changes. Different executables have access to to different collections of installed libraries, and it's important to make sure that your scripts are run using the executable that has their dependencies installed. If you use env shebangs, there's no way to do that - you're limited to either using the first executable on the path or manually specifying the executable on the command line to bypass the shebang.

I'm not saying that you shouldn't use env shebags, because they really are fine for a lot of scripts. However, you should always be mindful of what they mean and how that could break your script in the future.

My experience is exactly the opposite wrt fragility: fully hardcoded paths assume that the hardcoded path can and will have all the required dependencies, which — at least for modern Python development — is always the wrong assumption to make. Essentially, it only ever works if the script is run on the same version of the same distribution with the same package manager and installed packages as the original developer of the script. This is the most brittle a script can get.

> it's important to make sure that your scripts are run using the executable that has their dependencies installed.

Which a hardcoded shebang path does not do, it assumes these things but does not assert them and does not "make sure" of anything.

> If you use env shebangs, there's no way to do that

There's no way to make unwarranted assumptions is about as far as it goes: using env shebangs, the caller of the utility has control over what happens and which executable gets called (even indirectly)

> you're limited to either using the first executable on the path or manually specifying the executable on the command line to bypass the shebang.

Or specify a PATH when calling the script, or run the script in overridden PATH environments (e.g. virtualenvs), or...

> I'm not saying that you shouldn't use env shebags, because they really are fine for a lot of scripts.

And I went (and would still go) much further and state that they're the right solution for the vast majority of scripts and utilities.

> However, you should always be mindful of what they mean and how that could break your script in the future.

So should you be with hardcoded shebang paths, and they are much more likely to break a script across porting than env shebangs.

Most of the Linux distros I've used have the generic executable linked to a specific version: ls -l /usr/bin/python -> python2.6

If you need a specific version because of libraries or whatever, just use: #!/usr/bin/env python2.7

Nice tip!

Reply on news.ycombinator.com