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 /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