4 ms·

"Neither env shebangs nor absolute path shebangs are generally ‘better.’ Either one may get you in trouble when used in the wrong context." I generally agree o

"Neither env shebangs nor absolute path shebangs are generally ‘better.’ Either one may get you in trouble when used in the wrong context." I generally agree on the wisdom of "it depends and consider context", but.. An absolute path is going to assume others have the same setup. The downside claimed for using #!/usr/bin/env seems to be: - that the PATH needs to be setup correctly for interactive/non-interactive shells. (Which will be true of just executing that command in a script, anyway). - and that the program might be a different version than expected (which an absolute path doesn't solve either). Using #!/usr/bin/env is a much better default to go with, and will be the better option almost all the time.

tyingq 5y ago
One use case where #!/usr/bin/env can go wrong is with cron jobs. They don't typically pick up the same path as an interactive login or shell. So it's easy, for example, to get get a python 2 interpreter when you were expecting python 3 with "#!/usr/bin/env python"
- IshKebab 5y ago
  You should always explicitly use `python3` rather than `python` and hoping it is version 3.
  - tyingq 5y ago
    Well, even then, you may not get the python3 you expect with "#!/usr/bin/env python3" in a cron job. I imagine a fair amount of this is happening now, with Xcode installing it's own python3 on a bunch of Macs.
derefr 5y ago
> An absolute path is going to assume others have the same setup. Certain absolute path locations are standardized by POSIX. Including the absolute path of /usr/bin/env. > and that the program might be a different version than expected (which an absolute path doesn't solve either). ...and those programs in those standard locations are required by those same standards to behave ABI-compatibly with their behavior at time of standardization. Which is why e.g. /bin/bash bothers to strip out features when called as /bin/sh — the interpreter at /bin/sh must be no less and no more than the particular feature-set of the Bourne shell version that POSIX was standardized upon.

tyingq 5y ago

One use case where #!/usr/bin/env can go wrong is with cron jobs. They don't typically pick up the same path as an interactive login or shell. So it's easy, for example, to get get a python 2 interpreter when you were expecting python 3 with "#!/usr/bin/env python"

IshKebab 5y ago
You should always explicitly use `python3` rather than `python` and hoping it is version 3.
- tyingq 5y ago
  Well, even then, you may not get the python3 you expect with "#!/usr/bin/env python3" in a cron job. I imagine a fair amount of this is happening now, with Xcode installing it's own python3 on a bunch of Macs.

derefr 5y ago

> An absolute path is going to assume others have the same setup. Certain absolute path locations are standardized by POSIX. Including the absolute path of /usr/bin/env. > and that the program might be a different version than expected (which an absolute path doesn't solve either). ...and those programs in those standard locations are required by those same standards to behave ABI-compatibly with their behavior at time of standardization. Which is why e.g. /bin/bash bothers to strip out features when called as /bin/sh — the interpreter at /bin/sh must be no less and no more than the particular feature-set of the Bourne shell version that POSIX was standardized upon.