3 ms·

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

by tomku 14y ago

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.

masklinn 14y ago
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.
Nick_C 14y ago
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

by tomku 14y ago

masklinn 14y ago

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.

Nick_C 14y ago

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