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.
On Fri, Dec 10, 2010, James B. Byrne 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?
The /bin/env command uses the $PATH environment variable to find the argument. If you want to invoke a specific version of ruby, change the PATH variable or replace this with:
#!/usr/local/bin/ruby
Bill
On 12/10/2010 11:20 AM, James B. Byrne 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?
Why not just change the shebang line to use
#!/usr/local/bin/ruby
?
At Fri, 10 Dec 2010 14:20:12 -0500 (EST) CentOS mailing list centos@centos.org 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?
PATH=/usr/local/bin:$PATH
Compare the value of PATH in your shell vs. the cronjob.
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.
On Fri, Dec 10, 2010 at 2:20 PM, James B. Byrne byrnejb@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.
On 12/12/10 06:50, Brian Mathis wrote:
On Fri, Dec 10, 2010 at 2:20 PM, James B. Byrnebyrnejb@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 /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
-
Benjamin Franz -
Bill Campbell -
Brian Mathis -
David Sommerseth -
James B. Byrne -
Robert Heller