You can do “/bin/bash -e” but not “/usr/bin/env bash -e”. Same for python etc.

Good point about freebsd - I remember running into that exact problem. But I think I just symlinked it.

https://unix.stackexchange.com/questions/29608/why-is-it-bet... has more info on the pitfalls.

In my experience env causes problems, whereas explicit binary call always works (assuming the path exists). Not sure why I was downvoted.

Is this a problem with env? What does the "-e" flag do anyway? "man bash" proved unenlightening.

It's not because of env. It's just that shebangs are limited to passing one optional argument to the executable specified. The way they're parsed is the executable path, and if there's a space, then the rest of the line (including any additional spaces) is interpreted as 1 argument to the executable.

EDIT: -e causes bash to exit on the first command that returns with an error (returns with a non-zero return code). It's documented in `man bash` where it documents the `set` builtin command.

Thanks for clarifying. In that case, one could imagine an env capable of parsing its single argument into the multiple intended arguments? I admit that I never dreamed that the "set" builtin would have the information about "bash -e" while the initial "OPTIONS" section did not. Why not look under the "cd", "echo", "fc", "read", or "ulimit" builtins? Somewhat helpfully, the "COMMAND EXECUTION ENVIRONMENT" section talks about how "-e" is inherited but not what it means. Ah, man pages.

Well, to be fair, the first sentence in OPTIONS is:

> All of the single-character shell options documented in the description of the set builtin command can be used as options when the shell is invoked.

It's easy to miss though, when one's accustomed to quickly searching with "/".

EDIT: On the imagined env, it might be possible. I wonder what aspects of shebangs are portable across the various unix derived OSs. It may be that there's some systems where it only takes non-whitespace characters as the first argument and drops everything else after encountering another space. There might be also other limitations that one should consider when making more use of shebangs, like the character limit of the lines. For example, I think linux only takes the first 127 characters of the shebang and ignores everything else; other systems might take less. I encountered that limit when writing this answer:

https://unix.stackexchange.com/questions/365436/choose-inter...

EDIT 2: If you were to do such a program, it will probably also need to implement quoting and escaping syntax. The difficult part is that, since it wouldn't be a standard program to have, it'd have to be listed as a dependency of whatever projects you use it in, and I wonder if the benefit really outweighs the cost of having yet another dependency. I can't see something like this gaining wide adoption.

Haha thanks that is why I missed it.

Interestingly, FreeBSD used to allow for multiple arguments.

Do you know why they stopped?

So they did it for compatibility. In the end, it seems better to take everything as 1 argument instead of simply splitting on spaces, without having support for quoting and escaping. That way you can have arbitrary code with spaces in the shebang if that's ever a good idea.

It is probably silly to dream that kernels will change their behavior, if FreeBSD had to revert such an improvement. However as you describe env is actually downstream of the kernel, so if it were improved we could envision shebangs like the following:

  #!/usr/bin/env --new-env-behavior-parse-all-args=bash -e

Some people might prefer a less verbose flag, but perhaps making it extra-yucky would improve adoption?

> You can do “/bin/bash -e” but not “/usr/bin/env bash -e”.

Makes sense. Thanks for clarifying. I had a feeling I wasn't understanding your point.

He probably means you can't:

    #!/usr/bin/env bash -ex

but you can:

    #!/bin/bash -ex

Ah, makes sense then. Thanks for clarifying.