Feature #5445
openNeed RUBYOPT -r before ARGV -r
Description
Libraries given by -r options in RUBYOPT should be loaded before ones in direct command line arguments.
I use a custom load system for development that I have been using for years and it works very well for me. But Ruby has some edge cases that prevents it from being feature complete. One of these is the order in which RUBYOPT is applied vs. -r command line option.
My custom loader is too large to include here, so I will simply demonstrate the problem with simple sample code:
$ cat req.rb
p "Custom Require"
module Kernel
alias :require0 :require
def require(*a)
puts "Kernel#require"
p a
require0(*a)
end
class << self
alias :require0 :require
def require(*a)
puts "Kernel.require"
p a
require0(*a)
end
end
end
If we load this via RUBYOPT, the result is:
$ RUBYOPT=-r./req.rb ruby -rstringio -e0
Custom Require
But if we load via -r the result is:
$ ruby -r./req.rb -rstringio -e0
Custom Require
Kernel#require
["stringio"]
I would ask that the output of both invocations to be identical.
(Note, the -T option should still allow RUBYOPT to be omitted regardless.)
Updated by nobu (Nobuyoshi Nakada) about 13 years ago
- Tracker changed from Bug to Feature
=begin
A patch follows.
diff --git i/ruby.c w/ruby.c
index 2e6751f..3c8bb3a 100644
--- i/ruby.c
+++ w/ruby.c
@@ -1251,9 +1251,13 @@ process_options(int argc, char **argv, struct cmdline_options *opt)
VALUE src_enc_name = opt->src.enc.name;
VALUE ext_enc_name = opt->ext.enc.name;
VALUE int_enc_name = opt->intern.enc.name;
-
long req_count = opt->req_list ? RARRAY_LEN(opt->req_list) : 0;
opt->src.enc.name = opt->ext.enc.name = opt->intern.enc.name = 0;
moreswitches(s, opt, 1); -
if (req_count && RARRAY_LEN(opt->req_list) > req_count) {
-
rb_ary_rotate(opt->req_list, req_count);
-
}
if (src_enc_name)
opt->src.enc.name = src_enc_name;
if (ext_enc_name)
=end
Updated by mame (Yusuke Endoh) about 13 years ago
Hello,
2011/10/14 Thomas Sawyer transfire@gmail.com:
Libraries given by -r options in RUBYOPT should be loaded before ones in direct command line arguments.
How about adding a new environment variable, such as RUBYOPT_BEFORE?
I don't think it is a good idea to change the order because of
compatiblilty.
--
Yusuke Endoh mame@tsg.ne.jp
Updated by trans (Thomas Sawyer) about 13 years ago
My thought is that it makes sense that RUBYOPT comes first, b/c it defines starting environment.
In production is -r even used? Likelihood of compatibility issue is probably extremely low.
Updated by mame (Yusuke Endoh) over 12 years ago
- Status changed from Open to Assigned
- Assignee set to matz (Yukihiro Matsumoto)