On Fri, Dec 23, 2016 at 08:11:15AM +1100, Sean Crosby wrote:
I've taken to using /usr/bin/env a bit more because of the max length limit in shebang lines. We store newer versions of Ruby, Python etc on a separate filesystem, where there are many versions of these directories, and they are hidden down quite far in the dirtree. So we regularly hit the max shebang length limit of 128 characters.
that's one of the things that symlinks are for. e.g. I have python2.6, 2.7, 3.1, 3.2, 3.4, and 3.5 all installed in /usr/bin, with symlinks python & python2 pointing to 2.7, and python3 pointing to 3.5 that's all managed automatically by the system python packages. if i ever need a custom compiled python 3.x or whatever, I can either make a package the same way or install it under /usr/local and create and/or update the symlink as needed. or i can compile and install it anywhere and make a specific symlink (e.g. /usr/local/bin/python.custom) pointing to it - avoiding the 128 character #! limit. python scripts have either a specific versioned binary name in the #! line or just #!/usr/bin/python or #!/usr/bin/python2 for the latest python 2.x or #!/usr/bin/python3 for the latest python 3.x. at some point in the future, python3 will become the default python and /usr/bin/python will point to it. and the scripts work exactly the same, using the exact same interpreter (with the exact same set of library modules) no matter who runs them or what environment they're run in (e.g. from a shell, or from cron, or a web server). Consistency and predictability are important. As is manual control/override where needed. similarly, I have ruby1.9.1, ruby2.0, ruby2.1, ruby2.2, and ruby2.3 in /usr/bin, with /usr/bin/ruby a symlink pointing to ruby2.3 craig ps: to me, using #!/usr/bin/env is just a variant of something that i've hated ever since my first unix sysadmin job (actually, before that when I was just a user or programmer) - important things should not be buried in a programmer's home directory and dependent on their idiosyncratic (and undocumented) environment settings. that's fine for your own tools and hacks and dev/testing versions, but when any such program moves beyond being a personal tool, it needs to be integrated into the system so that it works consistently for everyone who uses it. -- craig sanders <cas@taz.net.au>