ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: "Dan0042 (Daniel DeLorme) via ruby-core" <ruby-core@ml.ruby-lang.org>
To: ruby-core@ml.ruby-lang.org
Cc: "Dan0042 (Daniel DeLorme)" <noreply@ruby-lang.org>
Subject: [ruby-core:117605] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby
Date: Fri, 19 Apr 2024 02:21:56 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-108014.20240419022155.286@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-6648.20120626075637.286@ruby-lang.org

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


I'd like to revive this proposal.

The OP mentions calling a subcommand with the same options/flags as the current interpreter, and that's a fine use case. As for me I'm also interested in re-executing the current script while keeping ruby options/flags.

Some time ago I tried writing a rbenv alternative based on the idea of adding "-r versionchecker" to RUBYOPT and then re-executing the current script with a different interpreter if the .ruby-version file specified a different version. No bash, no shims! But it was not to be; the lack of this proposed API made this infeasible. In particular if ruby is executed with the `-e` argument it appears impossible to get back the value.

I imagine this feature would also be very useful for web servers that need to re-execute upon receiving USR2. Currently they need to have all their options in RUBYOPT.

Since the path to the current interpreter is already in `RbConfig.ruby` I would suggest `RbConfig.ruby_args` for this API.

Then we could have a copy of the original $0 in `RbConfig.script` and a copy of the original ARGV in `RbConfig.script_args`, and to re-execute we can do
```ruby
exec(RbConfig.ruby, *RbConfig.ruby_args, *RbConfig.script, *RbConfig.script_args)
```

Extra features I'd like, if possible:

1) if ruby is invoked with `-e` argument(s), $0 is "-e" but RbConfig.script should be an array of the arguments:
```
ruby -e 'p 42' -e 'p RbConfig.script'
42
["-e", "42", "-e", "p RbConfig.script"]
```

2) if ruby is invoked with script on stdin, $0 is "-" but RbConfig.script should be an array with "-e":
```
echo 'p RbConfig.script' | ruby
["-e", "p RbConfig.script"]
```

If either of those extra features are impossible/undesirable, RbConfig.script should be `false` so that exec/system fails with TypeError rather than executing random things.


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

* 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/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

       reply	other threads:[~2024-04-19  2:22 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-6648.20120626075637.286@ruby-lang.org>
2024-04-19  2:21 ` Dan0042 (Daniel DeLorme) via ruby-core [this message]
2024-04-19 14:09 ` [ruby-core:117615] [Ruby master Feature#6648] Provide a standard API for retrieving all command-line flags passed to Ruby Eregon (Benoit Daloze) via ruby-core
2024-04-23 15:28 ` [ruby-core:117655] " kddnewton (Kevin Newton) via ruby-core

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-108014.20240419022155.286@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    --cc=noreply@ruby-lang.org \
    --cc=ruby-core@ml.ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).