Re: How do you know what the main file in Ruby Projects is?

I suppose the problem is that osx comes with a system ruby install which is d=
ifficult to change. In fact on osx I never want anything using system ruby, b=
ut osx internals can rely on that ruby so I don't want to change it. What sh=
ould one do in this situation to not use env? I'd probably be quite upset ge=
m publishers who used 1.9 syntax used the ruby version in /use/bin

Sent from my iPhone

On Apr 5, 2013, at 6:21 PM, "D. Deryl Downey" <[e-mail]> wrote:

> The simplest issue is that env uses the first ruby it finds in the PATH va=
riable. Now, say you're running an application that works fine, and uses Rub=
y 1.9.x specific syntax such as the new Hash syntax. Now, the PATH gets modi=
fied and the Ruby in the path is changed to, say, Ruby 1.8.7. The applicatio=
n in question (script/whatever) will puke. Ruby 1.8.x doesn't understand tha=
t new syntax.
>=20
> All it took was a simple path change to break your up-to-now working scrip=
t/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 chan=
ged. You change *that* binary, then all bets are off.
>=20
> There are a number of other possible scenarios, but that is the easiest to=
 make clear.
>=20
>=20
> -----Original Message-----
> From: Matthew Mongeau [mailto:[e-mail]]=20
> 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?
>=20
> I'm interested in the issue with using env, but I find you explanation a b=
ut hard to follow. What are some situations that lead to the problems you ar=
e describing. I'm currently using env in some gems and if there is a strong a=
rgument against it, I don't mind switching it.=20
>=20
> Sent from my iPhone
>=20
> On Apr 5, 2013, at 4:36 PM, Matt Lawrence <[e-mail]> wrote:
>=20
>> On Sat, 6 Apr 2013, Hans Mackowiak wrote:
>>=20
>>> Matt Lawrence wrote in post #1104625:
>>>> On Sat, 6 Apr 2013, D. Deryl Downey wrote:
>>>>=20
>>>>> Actually its not wrong. What it does is explicitly state which ruby=20=

>>>>> interpreter to use rather than using env to determine by finding=20
>>>>> the first one in the path. His way in no way shape or form is wrong=20=

>>>>> provided that ruby actually lives there.
>>>>=20
>>>> As and operations person, I will point out that using #!/usr/bin/env=20=

>>>> ruby is a really, really bad idea for a production system.
>>>=20
>>> or on the other hand, when #!/usr/bin/ruby is used in a gem, users=20
>>> gets problems because it does not work with rbenv, rvm or /usr/local=20
>>> builded ruby, env can be easier changed, even in a production system
>>=20
>> No, it can't.  Been there, done that.  Most developers are really smart a=
nd 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 environmen=
t.  Like I said, use env and you should be on the hook for the rest of your l=
ife for any issues that occur.
>>=20
>> -- Matt
>> It's not what I know that counts.
>> It's what I can remember in time to use.
>=20
>=20
>=20