Timeline for Why is it better to use "#!/usr/bin/env NAME" instead of "#!/path/to/NAME" as my shebang?
Current License: CC BY-SA 3.0
17 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 14, 2022 at 13:30 | comment | added | Mikko Rantalainen | @cas Oh... I wasn't aware that python is incompatible even between minor versions, too. That's one more reason not to use python for anything important. | |
| Apr 14, 2022 at 12:46 | comment | added | cas | @MikkoRantalainen unfortunately, it's more complicated than that for python. python manages to have incompatibilities even within the same major version....and complicated even further by python expecting separate lib directories for each minor version too. It's like they go out of their way to ensure breakage on every release. | |
| Apr 14, 2022 at 11:31 | comment | added | Mikko Rantalainen | I fully agree with this answer and I just want to mention that the real problem is people writing /usr/bin/python instead of /usr/bin/python2 or /usr/bin/python3 because those are two different programming languages! The /usr/bin/python should have been re-defined to always point to python2 compatible version and we wouldn't even have this whole mess. The same with ruby – if you make incompatible variant, change the name of the interpreter binary, don't mess with the PATH. | |
| Jul 29, 2020 at 11:14 | comment | added | DrHyde | I wish I could upvote this a thousand times for demonstrating use of ed(1) in a pipeline! | |
| Feb 23, 2020 at 4:12 | comment | added | vonbrand | @xdhmoore, /usr/bin/env is dependable, where the heck python lives is anybody's guess (most Linux systems have /usr/bin/python, on non-Linux systems it is usually an "unsupported addon" buried somewhere funky). | |
| Jan 16, 2020 at 2:10 | comment | added | xdhmoore | env is no more guaranteed to be in /usr/bin/env than bash is guaranteed to be in /bin/bash or python in /usr/bin/python - This seemed right at first but then I thought, what is the likelihood of me or someone else putting env in a weird place vs putting python in a weird place? I'm much more likely to put python in a wacky place, so env does seem more predictable to me. | |
| Jan 26, 2018 at 14:57 | comment | added | jstine | I wish I could upvote this a thousand times, because it's actually a great answer either way -- if someone uses /usr/bin/env and I need to get rid of it locally, or if they didn't use it and I need to add it. Both cases can occur, and therefore the scripts provided in this answer are a potentially useful tool to have in the toolbox. | |
| Jun 4, 2016 at 3:17 | history | edited | cas | CC BY-SA 3.0 | fixed example script to use `realpath`. |
| Jun 4, 2016 at 1:26 | history | edited | cas | CC BY-SA 3.0 | added third problem. and examples of scripting shebang line edits |
| Oct 25, 2015 at 17:27 | comment | added | jlliagre | That is precisely what env is helping to avoid: depending on a sysadmin or OS specific technical knowledge unrelated to python or whatever. | |
| Oct 25, 2015 at 10:51 | comment | added | cas | non-sysadmins can ask their sysadmin to do it. or they can simply edit the script and change the #! line. | |
| Oct 25, 2015 at 10:38 | comment | added | jlliagre | Not everybody is a sysadmin on their machine. The env solution is aimed at helping non operating system specialists to copy/paste or download scripts that have a good chance to work as is. It is also one of the methods that allow more advanced users to experiment with multiple unchanged scripts to be executed by custom versions of the target interpreter by only changing their PATH / PATH order (sorry about that too long sentence...) | |
| Oct 25, 2015 at 8:37 | comment | added | cas | The interpreter path issue is easily fixed by a sysadmin with symlinks, or by the user editing their script. It's certainly not a significant enough problem to encourage people to put up with the all of the other issues caused by using env on the shebang line that are mentioned here and on other questions. That's promoting a bad solution in the same kind of way that encouraging csh scripting is promoting a bad solution: it kind of works but there are much better alternatives. | |
| Oct 25, 2015 at 8:16 | comment | added | jlliagre | Sorry, you are right about the argv[0] issue, I was confusing with another thread. Your first point is still questionable. Using env in the first place assumes the command to launch is in the user's PATH and is a portable way to publish a script giving it the best opportunity to be executable whatever the target system. If that target command (e.g python, perl) is not in the PATH, there is no portable way to specify it in the script shebang anyway. | |
| Oct 25, 2015 at 7:55 | comment | added | cas | Nobody else here has mentioned the ARGV[0] problem. And nobody has mentioned the /path/to/env issue in a form that directly addresses one of the arguments for using it (i.e. that bash or perl might be in an unexpected location). | |
| Oct 25, 2015 at 7:23 | comment | added | jlliagre | Both of these potential issues have already been mentioned in existing answers. In any case, env is much more likely to be in /usr/bin/env than bash or python being in any specific location. | |
| Oct 25, 2015 at 6:18 | history | answered | cas | CC BY-SA 3.0 |