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

Ruby
1

Hi Ruby people,

I have been using C for a while and I was wondering how you can tell
what the main file is in a multi file Ruby project?
Ruby is great, I love it as a language. thanks to all who take time to
post here with answers to our newb questions.

2

Subject: How do you know what the main file in Ruby Projects is?
Date: sab 06 apr 13 03:30:06 +0900

Quoting peteV ([email protected]):

I have been using C for a while and I was wondering how you can tell
what the main file is in a multi file Ruby project?

Ruby is an interpreted language - you always execute the interpreter
by passing to it the name of a script, some inline code or code fed
via the standard input. There is no default ‘main’. The script, and
everything else that is pulled in by it, is evaluated sequentially.

Of course, the code within method definitions is not executed
immediately. But the rest is.

If you don’t actually run the interpreter yourself, chances are you
run a script that is made executable, and where the first line is
something like:

#!/usr/bin/ruby

Try this, for example:

less which irb

If you have a multi-file project, check what command you are supposed
to execute.

Carlo

3

On Fri, Apr 5, 2013 at 8:30 PM, peteV [email protected] wrote:

Hi Ruby people,

I have been using C for a while and I was wondering how you can tell what
the main file is in a multi file Ruby project?
Ruby is great, I love it as a language. thanks to all who take time to
post here with answers to our newb questions.

robert@fussel:~$ ruby a.rb
a.rb
a.rb
robert@fussel:~$ cat -n a.rb
1
2 puts $0
3
4 load ‘b.rb’
5
robert@fussel:~$ cat -n b.rb
1
2 puts $0
3

Cheers

robert

4

Subject: Re: How do you know what the main file in Ruby Projects is?
Date: sab 06 apr 13 04:56:41 +0900

Quoting Hans M. ([email protected]):

#!/usr/bin/ruby

this line is wrong, use
#!/usr/bin/env ruby

??

It is certainly not wrong.

It may well be that you want to be sure about which interpreter you
will call

Carlo

5

Carlo E. Prelz wrote in post #1104616:

Subject: How do you know what the main file in Ruby Projects is?
Date: sab 06 apr 13 03:30:06 +0900

If you don’t actually run the interpreter yourself, chances are you
run a script that is made executable, and where the first line is
something like:

#!/usr/bin/ruby

this line is wrong, use
#!/usr/bin/env ruby

6

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.

Your way is the more common way but that doesn’t make it the defacto
Right
Way™

7

Matt L. wrote in post #1104625:

On Sat, 6 Apr 2013, D. Deryl D. 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

8

On Sat, 6 Apr 2013, D. Deryl D. 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. It introduces an
exepect behaviour when doing system upgrades and migrations or when
somebody changes the .profile for the account. Please don’t deploy
stuff
like that into production unless you are willing to include your phone
number and accept calls in the middle of the night for the next 5+
years.

– Matt
It’s not what I know that counts.
It’s what I can remember in time to use.

9

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

10

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.

11

On Sat, 6 Apr 2013, Hans M. wrote:

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.

12

On Apr 6, 2013 8:03 AM, “Matthew Mongeau” [email protected]
wrote:

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.

Question: why does a gem have a shebang line at all? Aren’t gems always
only ever required by other ruby scripts?

13

I suppose the problem is that osx comes with a system ruby install which
is difficult to change. In fact on osx I never want anything using
system ruby, but osx internals can rely on that ruby so I don’t want to
change it. What should one do in this situation to not use env? I’d
probably be quite upset gem publishers who used 1.9 syntax used the ruby
version in /use/bin

Sent from my iPhone

14

Question: why does a gem have a shebang line at all? Aren’t gems always
only ever required by other ruby scripts?

When they have executable scripts like rails.

15

Looking into rails, even it uses /usr/bin/env for determining the ruby
version.

16

On Sat, 06 Apr 2013 01:16:15 +0200, Matthew K.
[email protected] wrote:

Question: why does a gem have a shebang line at all? Aren’t gems always only
ever required by other ruby scripts?

Some gems include executable scripts. Examples would be Ocra or
ruby_parser.

You can use gem install --env-shebang <gemname> to fix this for
yourself.

Also, what was this topic about?..

17

Interesting. How do they get added to the shell path, so you can execute
them? Or do you have to write
/usr/local/lib/ruby/gems/1.9.3/gems/foo/lib/foo-cli.rb
or whatever to actually run them?

My system ruby installs them into /usr/bin. So I get /usr/bin/rails.
When
using ruby version managers they install them into more sane locations.

18

On 6 April 2013 09:44, Bartosz Dziewoński [email protected] wrote:

You can use gem install --env-shebang <gemname> to fix this for yourself.

Interesting. How do they get added to the shell path, so you can
execute
them? Or do you have to write
/usr/local/lib/ruby/gems/1.9.3/gems/foo/lib/foo-cli.rb or whatever to
actually run them?