Re: luv-main Digest, Vol 64, Issue 15
Message: 1 Date: Fri, 23 Dec 2016 08:11:15 +1100 From: Sean Crosby <richardnixonshead@gmail.com> To: Craig Sanders <cas@taz.net.au>, luv-main <luv-main@luv.asn.au> Subject: Re: /usr/bin/env Message-ID: <CADg9O+Ncb-3DWJBdBc8mvBkYJYqitVcs+Wht5NxnYrXpg4K17g@mail.gmail. com> Content-Type: text/plain; charset="utf-8"
On 23 December 2016 at 01:37, Craig Sanders via luv-main < luv-main@luv.asn.au> wrote:
the one argument in favour of doing this (that the script will be run by the first matching interpreter found in the PATH) is both a blessing and a curse. at best it's a minor convenience. at worst, it's a potential security
risk
- it's not an accident or an oversight that every unix system since the #! line was invented DOESN'T search $PATH for the interpreter.
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.
We use the "modules" environment (TACC's lmod implementation specifically) for this type of thing. https://www.tacc.utexas.edu/research-development/tacc-projects/lmod It allows multiple versions of packages to exist without library collisions and so on. Loading the appropriate modules allows the user to set up the execution environment and even swap between versions if necessary. I was a late conversion, but wouldn't be without now. -- - https://picasaweb.google.com/107747436224613508618 -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- "Voting is a lot like going to Bunnings really: You walk in confused, you stand in line, you have a sausage on the way out and at the end, you wind up with a bunch of useless tools" Joe Rios -
On Fri, Dec 23, 2016 at 01:06:47PM +1100, Andrew Mather wrote:
We use the "modules" environment (TACC's lmod implementation specifically) for this type of thing.
https://www.tacc.utexas.edu/research-development/tacc-projects/lmod
It allows multiple versions of packages to exist without library collisions and so on. Loading the appropriate modules allows the user to set up the execution environment and even swap between versions if necessary.
this looks interesting. i'll have to read more about it but at first sight it seems like a specific language and system for setting up the environment for a particular program/script. one of the main reasons i prefer wrapper scripts (or symlinks) is that they don't rely on undocumented and unknown settings (PATH, LDPATH, etc) in some random individual's environment. scripts document those settings explicitly. symlinks just use the standard system environment. this has the huge benefit of NOT relying on fallible human memory, resulting in reproducible, auditable, and easily debugged software usage. also avoids seemingly random breakage from changes to the environment - "why doesn't this work? it ran perfectly 3 weeks ago when i last ran it." i'm kind of surprised that a language with the slogan "explicit is better than implicit" is one of the main perpetrators of the #!/usr/bin/env abomination. craig -- craig sanders <cas@taz.net.au>
participants (2)
-
Andrew Mather -
Craig Sanders