Bug #12128

Strings in `ARGV` are frozen

Added by sawa (Tsuyoshi Sawada) over 4 years ago. Updated over 4 years ago.

Target version:


It is not clear how the frozen status of strings in ARGV are to be described, but regardless of what I try to do (i.e. set frozen string pragma as false, which is probably irrelevant because the strings are already created at the time of file load), the strings appear frozen. I ran the following file foo.rb as ruby foo.rb bar:

#!/usr/bin/env ruby
# frozen_string_literal: false
ARGV.first.frozen? #=> true
ARGV.first.upcase! #=> can't modify frozen String (RuntimeError)

I believe this is a bug. If not, I would like to know what determines the frozen status of the strings in ARGV. Is it a feature that they are always frozen?

Updated by sawa (Tsuyoshi Sawada) over 4 years ago

Sorry, I found that it is indeed a feature that they are frozen. Please reject this.

Updated by 0x0dea (D.E. Akers) over 4 years ago

Be advised that you can say!(&:+@) if you really want to modify the elements in-place, but that's probably not the best idea.

Updated by shevegen (Robert A. Heiler) over 4 years ago

I believe that this is actually how ruby may have behaved before the transition into frozen strings
already; at the least, I seem to distinctly remember that, if I write a method such as:

require 'pp'

def foo(i = ARGV)
  pp i


Then the input was considered "tainted", which I assume may refer to external input in
general, and the Strings that are in ARGV were always frozen.

So I think one always had to write code that would handle this situation properly. This
does not say anything about your proposal by the way, I have no particular pro or contra
opinion whatsoever, but I think that this was how ruby always treated ARGV. (I would usually
pass this through a setter method that will do the proper sanitizing for me; that is, how
I would respond to user input in general. It may be interesting to know how OptionParser
/ optparse handles commandline input, I personally tend to be very lazy and am often fine
for small classes to just check against an internal menu() method, which would select
the behaviour for the given class, such as --disable-colours and such to control colour
output, and so on and so forth.)

So to come to your question:

Is it a feature that they are always frozen?

I think that there was an old explanation for this, which probably is still valid today
since ARGV always were frozen, or perhaps at the least since when I was using ruby (I
have no idea about ruby 1.0 :D )

Updated by nobu (Nobuyoshi Nakada) over 4 years ago

  • Status changed from Open to Rejected

Also available in: Atom PDF