The simplest issue is that env uses the first ruby it finds in the PATH variable. Now, say you're running an application that works fine, and uses Ruby 1.9.x specific syntax such as the new Hash syntax. Now, the PATH gets modified and the Ruby in the path is changed to, say, Ruby 1.8.7. The application in question (script/whatever) will puke. Ruby 1.8.x doesn't understand that new syntax.

All it took was a simple path change to break your up-to-now working script/application, using 'env'. If you hardwire the Ruby in the script, the app/script will continue to work just fine. Now, *that* comment presupposes that the original Ruby binary still lives in the same spot, and hasn't been changed. You change *that* binary, then all bets are off.

There are a number of other possible scenarios, but that is the easiest to make clear.


-----Original Message-----
From: Matthew Mongeau [mailto:halogenandtoast / gmail.com] 
Sent: Friday, April 5, 2013 6:00 PM
To: ruby-talk ML
Subject: Re: How do you know what the main file in Ruby Projects is?

I'm interested in the issue with using env, but I find you explanation a but hard to follow. What are some situations that lead to the problems you are describing. I'm currently using env in some gems and if there is a strong argument against it, I don't mind switching it. 

Sent from my iPhone

On Apr 5, 2013, at 4:36 PM, Matt Lawrence <matt / technoronin.com> wrote:

> On Sat, 6 Apr 2013, Hans Mackowiak wrote:
> 
>> Matt Lawrence wrote in post #1104625:
>>> On Sat, 6 Apr 2013, D. Deryl Downey wrote:
>>> 
>>>> Actually its not wrong. What it does is explicitly state which ruby >>>> interpreter to use rather than using env to determine by finding 
>>>> the first one in the path. His way in no way shape or form is wrong >>>> provided that ruby actually lives there.
>>> 
>>> As and operations person, I will point out that using #!/usr/bin/env >>> ruby is a really, really bad idea for a production system.
>> 
>> or on the other hand, when #!/usr/bin/ruby is used in a gem, users 
>> gets problems because it does not work with rbenv, rvm or /usr/local 
>> builded ruby, env can be easier changed, even in a production system
> 
> No, it can't.  Been there, done that.  Most developers are really smart and are very good at solving problems when they arise.  That's a terrible way to run production, avoiding problems is the way to have a stable environment.  Like I said, use env and you should be on the hook for the rest of your life for any issues that occur.
> 
> -- Matt
> It's not what I know that counts.
> It's what I can remember in time to use.
>