[ruby-core:120265] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
From:
deivid via ruby-core <ruby-core@...>
Date:
2024-12-16 18:47:45 UTC
List:
ruby-core #120265
Issue #6648 has been updated by deivid (David Rodr=EDguez).
I agree with @Eregon and I believe ideally we would store `-C` in `ruby_arg=
s` but also provide a way to access the original working directory. That wa=
y people can choose where to re-run the original command.
In the case of Bundler, we would use this feature when we detect that a dif=
ferent version of Bundler is running than the one in the `Gemfile.lock` fil=
e. In that case, we would do some environment manipulation to make sure the=
locked version is actually used in a subsequent process, and then re-run t=
he original process. In our case, I think it would only make sense to re-ru=
n the original command in the original directory.
Alternatively, we could do some manipulation of original `-C` arguments to =
expand them to a single value with the absolute path where Ruby ends up run=
ning. But I like the `Process.original_working_directory` idea better.
----------------------------------------
Feature #6648: Provide a standard API for retrieving all command-line flags=
passed to Ruby
https://bugs.ruby-lang.org/issues/6648#change-111032
* 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 -- [email protected]
To unsubscribe send an email to [email protected]
ruby-core info -- https://ml.ruby-lang.org/mailman3/lists/ruby-core.ml.rub=
y-lang.org/