[CentOS] /bin/env

Sun Dec 12 12:24:05 UTC 2010
David Sommerseth <dazo at users.sourceforge.net>

On 12/12/10 06:50, Brian Mathis wrote:
> On Fri, Dec 10, 2010 at 2:20 PM, James B. Byrne<byrnejb at harte-lyne.ca>  wrote:
>> Please forgive my ignorance but I need a explanation of how to
>> accomplish the following since I cannot figure it out from the
>> documents.
>> I have a Ruby script with a shebang line that looks like this:
>> #!/usr/bin/env ruby
>> On one particular host I have two Ruby interpreters installed; one
>> the CentOS base version 1.8.6 in /usr/bin/ruby the other version
>> 1.8.7 in /usr/local/bin/ruby.  In my shell the which command finds
>> /usr/local/bin/ruby.  In a cron job the /usr/bin/ruby is used by the
>> /bin/env invocation.
>> My question is: How does one configure /bin/env to return the
>> /usr/local/bin/ruby version?  or does that question even make sense?
>> I have looked at the alternatives command but that seems just a tad
>> involved.  And since this is a production server I am not quite
>> ready to trust to RVM either.
>> In the short term I have simply removed the CentOS version which has
>> resolved the immediate issue.  However, I would like to know how to
>> handle this a little more elegantly in future.
> I'm not sure who came up with the "/usr/bin/env" thing (though I
> understand what they were trying to do), but it's exceedingly stupid.
> Even the smallest bit of testing would have easily revealed these
> kinds of problems with it.  The solution is to simply not use it and
> directly invoke the interpreter.

I probably disagrees with you here.  The /usr/bin/env thing solves issues with 
script interpreters being installed in a different location than usually, like 

You may disagree that this is not appropriate, but in some settings this is 
highly needed if you think about cross-platform support.  F.ex. a program 
using scripts which really only works with bash and on some Unix boxes that is 
unstalled under, say /usr/gnu/bin.

So by putting /usr/gnu/bin in an appropriate position in the global PATH 
variable and using /usr/bin/env ... that script will also work without any 
tweaks on a multitude of platforms without needing to be modified.  And of 
course you have similar issues when running a script via cron.

I would rather try to figure out why /usr/bin/env doesn't report 
/usr/local/bin early in the path for cron jobs to start with.  That's the core 
issue in this context.  So as was suggested earlier, compare the PATH variable 
from a shell and via a cron job and try to figure out why it is different.

kind regards,

David Sommerseth