Issue #15738 has been updated by shevegen (Robert A. Heiler).


> I would expect the command line arguments always override RUBYOPT arguments.

I agree.

I do not know all specifics but it makes sense to me as to agree with what Benoit
wrote in regards to explicit commandline option(s) being able to overrule environment
variables.

Otherwise the situation would be that any environment variable would always have a higher
precedence over an explicit commandline instruction given by the user at hand, which would
mean that people would not be able to use various --flags to have higher priority over 
environment variables. They would then, in this case, first have to disable the environment
variable, which I don't think makes a lot of sense.

In my largest gem I use the same approach to the behaviour Benoit described - I have code
that checks for some environment variables, but even if they exist, any explicit
commandline-instruction (in ruby passed through ARGV) would take precedence. The reasoning
goes like this "if the user specifically uses a certain option on the commandline, then
we have to trust that user to know what he/she is doing". Which I think is reasonable to
assume.

----------------------------------------
Bug #15738: RUBYOPT disables have precedence over the command line
https://bugs.ruby-lang.org/issues/15738#change-77377

* Author: Eregon (Benoit Daloze)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: ruby 2.6.2p47 (2019-03-13 revision 67232) [x86_64-linux]
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
From #15736:

It seems unexpected that the command line argument doesn't override the RUBYOPT options:

```
$ RUBYOPT=--disable-gems ruby --enable=gems -e 'p defined?(Gem)'
nil
```

That seems a bug. I would expect the command line arguments always override `RUBYOPT` arguments.

This:
```
$ ruby --disable=gems --enable=gems -e 'p defined?(Gem)'     
"constant"
$ ruby --enable=gems --disable=gems -e 'p defined?(Gem)'
nil
```
works as expected.




-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>