Forum: Ruby-core [ruby-trunk - Bug #6648][Open] Provide a standard API for retrieving all command-line flags passed t

Posted by Charles Nutter (headius)
on 2012-06-26 00:57
(Received via mailing list)
Issue #6648 has been reported by headius (Charles Nutter).

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

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:
ruby -v: head


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
Posted by Nobuyoshi Nakada (nobu)
on 2012-06-26 01:28
(Received via mailing list)
Issue #6648 has been updated by nobu (Nobuyoshi Nakada).

Description updated


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

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:


=begin
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
=end
Posted by Charles Nutter (headius)
on 2012-09-19 09:09
(Received via mailing list)
Issue #6648 has been updated by headius (Charles Nutter).


ARGV is a special class; perhaps ARGV could have the methods?
----------------------------------------
Feature #6648: Provide a standard API for retrieving all command-line 
flags passed to Ruby
https://bugs.ruby-lang.org/issues/6648#change-29508

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:


=begin
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
=end
Posted by Charles Nutter (headius)
on 2012-09-20 03:21
(Received via mailing list)
Issue #6648 has been updated by headius (Charles Nutter).


I was mistaken...it is ARGF, not ARGV that is a special class. ARGV is a 
normal array.

Another option: ENV, which is a special Hash-like class. ENV.vm_args, 
ENV.script, and ENV.script_args aren't bad.
----------------------------------------
Feature #6648: Provide a standard API for retrieving all command-line 
flags passed to Ruby
https://bugs.ruby-lang.org/issues/6648#change-29561

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:


=begin
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
=end
Posted by Charles Nutter (headius)
on 2012-10-14 21:51
(Received via mailing list)
Issue #6648 has been updated by headius (Charles Nutter).


Ping...we'd still like to have this to be able to build a unifying 
benchmark tool, which needs to be able to report the actual command-line 
arguments passed to the runtime. Current tricks are too ugly (parsing 
`ps` output, for example), and this would not be difficult to add.

I'm leaning toward ENV having a few special methods for this, but I'm 
open to other ideas.
----------------------------------------
Feature #6648: Provide a standard API for retrieving all command-line 
flags passed to Ruby
https://bugs.ruby-lang.org/issues/6648#change-30665

Author: headius (Charles Nutter)
Status: Open
Priority: Normal
Assignee:
Category:
Target version:


=begin
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
=end
Posted by mame (Yusuke Endoh) (Guest)
on 2012-11-24 00:53
(Received via mailing list)
Issue #6648 has been updated by mame (Yusuke Endoh).

Status changed from Open to Assigned
Assignee set to matz (Yukihiro Matsumoto)
Target version set to next minor

I'm sorry that matz didn't noticed this.

--
Yusuke Endoh <mame@tsg.ne.jp>
----------------------------------------
Feature #6648: Provide a standard API for retrieving all command-line 
flags passed to Ruby
https://bugs.ruby-lang.org/issues/6648#change-33676

Author: headius (Charles Nutter)
Status: Assigned
Priority: Normal
Assignee: matz (Yukihiro Matsumoto)
Category:
Target version: next minor


=begin
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
=end
Please log in before posting. Registration is free and takes only a minute.
Existing account (Switch to SSL-encrypted connection)
NEW: Do you have a Google/GoogleMail or Yahoo account? No registration required!
Log in with Google account | Log in with Yahoo account
No account? Register here.