[PATCH] bin/rails missing shebang line

AFAIK it will allow you to execute rails directly. Rubygem uses Kernel#load to pull in binfiles into a bin wrapper. Can you give a good use case for adding the shebang line?

Having a shebang in an executable does matter. Not everyone uses rubygems to manager their gems. You should take a look at the ruby packaging standard, the emerging standard for packaging ruby libraries. It clearly states: "Ruby executables SHOULD have a shebang line using env: #!/usr/bin/env ruby"

Here's what happens when I try use rails with rip:

$ rails
/Users/bozo/.rip/active/bin/rails: line 1: syntax error near unexpected token `('
/Users/bozo/.rip/active/bin/rails: line 1: `$:.unshift File.expand_path("../../lib", __FILE__)'

This happens because rip expects the rails executable to be a fully functional executable and have a shebang line. In not having a shebang, rails is choosing to be different than the majority of libraries out there, going against the emerging standard and forcing us to use rubygems. Is there a reason why rails should force us to use rubygems?

Yeah - I ran into in a context outside of rubygems (running the executable directly).

Attached is the patch.

I'm not against having the shebang, all the executable files on unix should have it. Ruby executables should have #!/usr/bin/env ruby
I've answered quickly because i had requested this some time ago, when rip just come out, and my request was denied.
But i agree so sorry for closing it :).

No, there's no reason rails should "force" you to use rubygems, however, the RPS has not yet provided one key aspect of information that is being completely ignored here:

The RPS also says:

Executables SHOULD NOT require 'rubygems' or modify the $LOAD_PATH.

So, my question to you is, if whatever packaging system you're using as an alternative does not generate bin wrappers with correct shebang lines that then use "exec" or "load" (exec would require modifying $RUBYLIB or similar), then you're going to have to violate the above to make this really work. I will describe why this is a problem after some further notes.

The only other way to make it work "by hand", is to launch the binary like this:

ruby -Irails/lib bin/rails

However this is also insufficient without the packaging system further modifying the load path prior to loading the application, as other dependencies are required to be on the load path, as is clearly demonstrated if you do in fact do this:

Thor is not available.
If you ran this command from a git checkout of Rails, please make sure thor is installed,
and run this command as `ruby /path/to/rails myapp --dev`

Please think about specifications that you're trying to use to force in patches, and if you're going to adhere to one portion of the spec, you should adhere to the rest, as such the patch technically should also be removing the following code from bin/rails:

rescue LoadError
  railties_path = File.expand_path('../../railties/lib', __FILE__)
  $:.unshift(railties_path)
  require "rails/cli"
end

I don't think that any of this is a good idea, I think that the original authors have actually made a very sane choice in how the software is currently loading its code. My largest problem with these kinds of suggestions is that they're based on an incomplete specification (that is still marked draft for good reason, and the standard has had my own input, I am not some random just making noise for no reason), and with an incomplete knowledge of good packaging procedures and load path management.

I would strongly suggest that better guidelines for making this work actually involve writing correct load path modification prior to launching the binfile in order to avoid the requirement for load path modifications within binfiles by library authors.

The reasoning behind this is:

Different packaging systems disagree on what to put in the load path. Some will use relative paths, and others will use absolute paths. There is no "right way", and in the spirit of ruby, the specification does not try to force either on the user, instead, it suggests a process by which users will not generate errors. The ignoring of this portion of the specification causes double load errors under conditions where the library is authored for one packaging system that believes in one mode of load path management, and then used by a different packaging system that has a conflicting view about whether or not the load path should contain absolute or relative paths. It is for this issue that chris included the aforementioned terms in the RPS, and this should be accounted for prior to further discussion on the topic.

It is also worth noting that rails supports the windows platform where the shebang is completely irrelevant, and the RPS currently makes no attempts to support this platform (yet), as it is still in draft and requires further input from Windows rubyists. Regardless of your personal opinions/beliefs about this platform, the languages continued support is important to users and again, should be accounted for in further discussion on the topic.

So, my question to you is, if whatever packaging system you're using as an alternative does not generate bin wrappers with correct shebang lines that then use "exec" or "load" (exec would require modifying $RUBYLIB or similar), then you're going to have to violate the above to make this really work. I will

I'm not exactly sure what require "rubygems" and $LOAD_PATH have to do with the she-bang line. As far as I'm concerned, the shebang line is a unix way to know which bin to use when running ./myexecutable. It's language agnostic.

Notice that my original usage was outside of a package management system. I think the way we should be writing code is by asking ourselves, "What can we make agnostic to all package managers, such that we aren't writing for any one given package manager, or a package manager at all".

Just because the shebang is being adopted, it doesn't mean that require "rubygems" and $LOAD_PATH must be as well.

It is also worth noting that rails supports the windows platform where the shebang is completely irrelevant, and the RPS currently makes no attempts to support this platform (yet), as it is still in draft and requires further input from Windows rubyists. Regardless of your personal opinions/beliefs about this platform, the languages continued support is important to users and again, should be accounted for in further discussion on the topic.

This is the only argument that seems to make sense to me. Windows doesn't seem to have an equivalent of the shebang, and neither does any other platform, AFAIK.

Without a correct load path, a shebang is completely useless. Add the shebang, and then run bin/rails:

% bin/rails
Thor is not available.
If you ran this command from a git checkout of Rails, please make sure thor is installed,
and run this command as `ruby /path/to/rails myapp --dev`

My point is simple. Packaging is required to setup the load path correctly in a way that satisfies out of repository dependencies. Packaging should not be modifying the load path implicitly. A packaging standard which is yet to be written at all would state this more clearly, the reasoning is similar to issues already described.

I don't necessarily have a problem with adding a shebang line, just as I don't have a problem with the modification of load path that bin/rails choses to do (specifically conditionally), as I think it maybe could make sense for rails, but, I don't think that using the RPS as a reason is valid at all.

My question is, in the environment you're proposing to use, will adding a shebang line actually make the binary work? If so, how is the load path being managed / how is the code being split in order to make this work?

In other words, can you provide a reason for adding it beyond "all unix binfiles have one"?

It is worth noting that whilst becoming increasingly rare, not all platforms with unix like shbang semantics have env(1) in /usr/bin/env.

It is also worth considering these:

http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/envir...
http://www.in-ulm.de/~mascheck/various/shebang/

This particularly becomes a problem on shared systems when using for example AWS keys in env vars or the like, and can lead to complete disclosure to other smart enough users.

Agreed they are digressions.

I have not objected to adding a shebang, I have objected to the reason being "because RPS says so", because as stated, consistent application of RPS would break other modes of use.

As far as the security implications go, they are worth noting, that is all.

As I said to Rohit, I don't think I should comment on rails tickets.

What I mean is, when I asked

My question is, in the environment you're proposing to use, will adding a shebang line actually make the binary work?"

If you said "yes", then my answer is +1. As indicated by:

I don't necessarily have a problem with adding a shebang line, just as I don't have a problem with the modification of load path that bin/rails choses to do (specifically conditionally), as I think it maybe could make sense for rails, but, I don't think that using the RPS as a reason is valid at all."

God I don't get how these things get so pathetic so damned fast.

Anyway, I'm waiting on an install to see if the answer is indeed yes, assuming it is, ofc, my answer is +1.

Automatic cleanup of spam.