On 12/12/10 06:50, Brian Mathis wrote:
> On Fri, Dec 10, 2010 at 2:20 PM, James B. Byrne<byrnejb@xxxxxxxxxxxxx> 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
/opt/my-own-tweaks/bin.
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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
