Issue #6648 has been updated by Dan0042 (Daniel DeLorme). mame (Yusuke Endoh) wrote in #note-23:
If you really want to "launch subprocess Ruby instances with the same settings", we might want to consider a more dedicated API for it, instead of parsing the command line to a string array and passing it to `Kernel#exec`.
A "more dedicated API" sounds not so good to me. It's more complex and also less versatile. One of the use cases was certainly to (re-)execute the current ruby, but in #note-10 I also mentioned executing a different version of ruby, like `exec("ruby-3.0", *filter_for_ruby30(RbConfig.ruby_args), script)`. This would not be possible with a dedicated API. Not to mention other potential uses like `RbConfig.ruby_args.include?('-v')` to know if the version number was printed. shyouhei (Shyouhei Urabe) wrote in #note-29:
Please note that I'm not necessarily against a way to call the current ruby executable. I just say doing so using exec is a bad idea, because exec is not designed for that purpose.
Maybe that's true on Windows, but on Unix `exec` is very much the normal and blessed way to re-execute the current program. I understand there are challenges on Windows, but they are inherent to the existing system/spawn methods, and will not change regardless of adding `RbConfig.ruby_args`. I don't think it's a good idea to hobble Unix just because Windows has some design flaws. nobu (Nobuyoshi Nakada) wrote in #note-33:
`Kernel#exec` is not implemented on Windows.
Then maybe `RbConfig.ruby_args` should not be implemented on Windows if it's such a problem? (Though I don't see why.) ---------------------------------------- Feature #6648: Provide a standard API for retrieving all command-line flags passed to Ruby https://bugs.ruby-lang.org/issues/6648#change-109158 * Author: headius (Charles Nutter) * Status: Assigned * Assignee: matz (Yukihiro Matsumoto) ---------------------------------------- Currently there are no standard mechanisms to get the flags passed to the currently running Ruby implementation. The available mechanisms are not ideal: * 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 command 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 simple command line. JRuby provides mechanisms to get all its command line options, but they require calling Java APIs from Ruby's API set. Rubinius provides its own API for 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 good host for this API. Something like... ``` class << RubyVM def vm_args; end # returns array of command line args *not* passed to the target script def script; end # returns the script being executed...though this overlaps 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 modified (i.e. you probably want the original args) end ``` -- https://bugs.ruby-lang.org/