[ruby-core:120266] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby

Issue #6648 has been updated by Dan0042 (Daniel DeLorme).


deivid (David Rodr=EDguez) wrote in #note-48:
> In the case of Bundler, we would use this feature when we detect that a d=
ifferent version of Bundler is running than the one in the `Gemfile.lock` f=
ile. In that case, we would do some environment manipulation to make sure t=
he locked version is actually used in a subsequent process, and then re-run=
 the original process. In our case, I think it would only make sense to re-=
run the original command in the original directory.

I don't follow the logic here. You would re-run the original command in the=
 original directory, just so that it can change back to the directory speci=
fied by `-C`. What for? Why not just stay in the CWD if you're going to win=
d up back there anyway? What's the point of using `Process.original_working=
_directory` and `-C` to cancel each other?

Oh, and here's an interesting tidbit I just learned that might impact how t=
o handle this: Ruby loads the script *after* changing to the dir specified =
by `-C`. That means `ruby -C foo x.rb` loads the script `foo/x.rb`. And whe=
n you re-execute you have to be in directory `foo` (or expand the script pa=
th).

----------------------------------------
Feature #6648: Provide a standard API for retrieving all command-line flags=
 passed to Ruby
https://bugs.ruby-lang.org/issues/6648#change-111033

* Author: headius (Charles Nutter)
* Status: Assigned
* Assignee: matz (Yukihiro Matsumoto)
----------------------------------------
Currently there are no standard mechanisms to get the flags passed to the c=
urrently running Ruby implementation. The available mechanisms are not idea=
l:

* Scanning globals and hoping they have not been tweaked to new settings
* Using external wrappers to launch Ruby
* ???

Inability to get the full set of command-line flags, including flags passed=
 to the VM itself (and probably VM-specific) makes it impossible to launch =
subprocess Ruby instances with the same settings.

A real world example of this is "((%bundle exec%))" when called with a comm=
and line that sets various flags, a la ((%jruby -Xsome.vm.setting --1.9 -S =
bundle exec%)). None of these flags can propagate to the subprocess, so odd=
 behaviors result. The only option is to put the flags into an env var (((|=
JRUBY_OPTS|)) or ((|RUBYOPT|))) but this breaks the flow of calling a simpl=
e command line.

JRuby provides mechanisms to get all its command line options, but they req=
uire calling Java APIs from Ruby's API set. Rubinius provides its own API f=
or accessing comand-line options, but I do not know if it includes VM-level=
 flags as well as standard Ruby flags.

I know there is a (({RubyVM})) namespace in the 2.0 line. If that namespace=
 is intended to be general-purpose for VM-level features, it would be a goo=
d host for this API. Something like...

```
  class << RubyVM
    def vm_args; end # returns array of command line args *not* passed to t=
he target script

    def script; end # returns the script being executed...though this overl=
aps with $0

    def script_args; end # returns args passed to the script...though this =
overlaps with ARGV, but that is perhaps warranted since ARGV can be modifie=
d (i.e. you probably want the original args)
  end
```



--=20
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]
 ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.rub=
y-lang.org/