Re: /bin/env

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux