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 d=
escribing. I'm currently using env in some gems and if there is a strong arg=
ument against it, I don't mind switching it.=20

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:
>=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
>>>> interpreter to use rather than using env to determine by finding the fi=
rst
>>>> one in the path. His way in no way shape or form is wrong provided that=

>>>> ruby actually lives there.
>>>=20
>>> As and operations person, I will point out that using
>>> #!/usr/bin/env 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 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
>=20
> No, it can't.  Been there, done that.  Most developers are really smart an=
d are very good at solving problems when they arise.  That's a terrible way t=
o 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 li=
fe 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