Feature #14240: warn four special variables: $; $, $/ $\

• Status: Closed
• Assignee: jeremyevans0 (Jeremy Evans)
• Target version: 3.0

[akr (Akira Tanaka)]

I think the four special variables for separators should be deprecated.

$/    input record separator (default argument for "gets")
$\    output record separator ("print" prints it at last)
$,    default separator for Array#join and print
$;    default separator for String#split

I feel many program doesn't work if they are set to non-default value.

Since they are global, not thread local,
we can not change these variables safely in a multi threaded program.

So, I think we should warn them (and delete them in future).

[matz (Yukihiro Matsumoto)]

• Related to Feature #14138: Define English.rb aliases by default and eliminate the library added

[matz (Yukihiro Matsumoto)]

Agreed.

Besides that, we should warn for $= and $., I think.

Matz.

[normalperson (Eric Wong)]

Shouldn't English posts be on ruby-core instead of ruby-dev?

[e-mail] wrote:

Agreed.

Besides that, we should warn for $= and $., I think.

I find $., $, and $/ useful for oneliners, at least. $.
especially

I'm fine with awk-compatible English.rb names ($NR, $ORS, $RS)
by default, but I do not like the long names in English.rb.

I like having some awk and Perl-isms in Ruby :>

[normalperson (Eric Wong)]

Shouldn't English posts be on ruby-core instead of ruby-dev?

[e-mail] wrote:

Agreed.

Besides that, we should warn for $= and $., I think.

I find $., $, and $/ useful for oneliners, at least. $.
especially

I'm fine with awk-compatible English.rb names ($NR, $ORS, $RS)
by default, but I do not like the long names in English.rb.

I like having some awk and Perl-isms in Ruby :>

[akr (Akira Tanaka)]

2017-12-26 17:55 GMT+09:00 Eric Wong [e-mail]:

Shouldn't English posts be on ruby-core instead of ruby-dev?

Oops. Sorry.

Besides that, we should warn for $= and $., I think.

I find $., $, and $/ useful for oneliners, at least. $.
especially

Hm. One idea to support oneliners is that warn the
special variables when -e option is not given.

Tanaka Akira

[akr (Akira Tanaka)]

2017-12-26 17:55 GMT+09:00 Eric Wong [e-mail]:

Shouldn't English posts be on ruby-core instead of ruby-dev?

Oops. Sorry.

Besides that, we should warn for $= and $., I think.

I find $., $, and $/ useful for oneliners, at least. $.
especially

Hm. One idea to support oneliners is that warn the
special variables when -e option is not given.

Tanaka Akira

[shevegen (Robert A. Heiler)]

By the way, the awk-inspired names such as $NR, $ORS, $RS,
also do not tell me anything. :-)

In fairness, I also have to admit that the english names also
do not always tell me that much more. Depends on the name.

http://ruby-doc.org/stdlib/libdoc/English/rdoc/English.html

$\ = ' -- '
"waterbuffalo" =~ /buff/
print $', $$, "\n"

versus

require "English"

$OUTPUT_FIELD_SEPARATOR = ' -- '
"waterbuffalo" =~ /buff/
print $POSTMATCH, $PID, "\n"

The second variant is a tiny bit more readable to me, but
I also can not tell you what $OUTPUT_FIELD_SEPARATOR really
means, without having to look at the docu. :)
And $POSTMATCH hmm... I can try to make a guess, but I am
not sure. I'd have to look at the docu. :D

Only $PID I can infer at once... to mean the PID of a
process. I like that name. Please tell me that it does
not mean anything else than PID ... :D

My brain takes more time for the first code variant and
in general, I try to write only very simply code in ruby
(which is also why I am absolutely bad at golfing and
one-liners, but I understand if people want to be able
to be super-succinct ... I remember the xmas tree in
code golfing, that's more like art than code though).

What actually makes me not use "English" there is the require
line - see also headius' suggestion elsewhere. I liked the recent
change in regards to pp for similar reason, less to type. :)
(Although I was using pp a LOT nonetheless, it is too useful to me
to not make use of it. It just is less typing for me now
past 2.5.x)

Anyway, I digress so I better stop now.

[normalperson (Eric Wong)]

Tanaka Akira [e-mail] wrote:

Besides that, we should warn for $= and $., I think.

2017-12-26 17:55 GMT+09:00 Eric Wong [e-mail]:

I find $., $, and $/ useful for oneliners, at least. $.
especially

Hm. One idea to support oneliners is that warn the
special variables when -e option is not given.

Can we have the warnings forever? (No removal, ever).
I would be happy with that :)

One important thing about oneliners is you won't find many
examples of them in code search engines to judge popularity.

[normalperson (Eric Wong)]

Tanaka Akira [e-mail] wrote:

Besides that, we should warn for $= and $., I think.

2017-12-26 17:55 GMT+09:00 Eric Wong [e-mail]:

I find $., $, and $/ useful for oneliners, at least. $.
especially

Hm. One idea to support oneliners is that warn the
special variables when -e option is not given.

Can we have the warnings forever? (No removal, ever).
I would be happy with that :)

One important thing about oneliners is you won't find many
examples of them in code search engines to judge popularity.

[Eregon (Benoit Daloze)]

I agree.
These global variables can only be useful in tiny scripts,
and even then I believe none of them are idiomatic Ruby code.

All of these are shortcuts saving at best a couple characters,
but also threaten any usage of gets/print/split/join methods in larger programs.
Giving an argument gets/print/split/join is much clearer and safer.

I was already thinking along the same lines 6 years ago about $, in https://bugs.ruby-lang.org/issues/5977,
after being caught by a bug of some library setting $, and breaking the rest in very surprising ways iirc.

[Eregon (Benoit Daloze)]

• Related to Feature #5977: Remove $, and avoid perlish global variables added

[akr (Akira Tanaka)]

We discussed this issue at today's developper meeting.

We (including matz) agree produce warnings for 5 variables ($; $, $/ $\ $.) when it is written in
ruby code except -e argument.

The warning is produced at compile time.
So the warning is produced once for each occurrence (even if it occurs in a loop).

Note that $= already produces a warning since ruby 1.9.

[nobu (Nobuyoshi Nakada)]

I wonder that aliased variables also should be warned, $-0, $-F, and aliases in English.rb.

Currently, aliases of $KCODE are also warned.
In other words, the feature of $KCODE is warned (and has no effect now).

Should we warn these four variable names, or their features?

[jeremyevans0 (Jeremy Evans)]

• File warn-5-gvars.patch warn-5-gvars.patch added

Attached is a patch that adds a deprecation warning for the 5 global variables ($; $, $/ $\ $.), unless inside ruby -e. However, there is use of these variables inside Ruby that should be fixed if we plan to make this change. I've already seen the following issues:

/path/ruby/lib/erb.rb:907: warning: global variable $. is deprecated
../.././ext/ripper/tools/preproc.rb: warning: global variable $/ is deprecated
/path/ruby/lib/rubygems/specification.rb:14: warning: global variable $. is deprecated

It is likely there are more issues than just these three.

[nobu (Nobuyoshi Nakada)]

It does not match to test rb_warn with assert_warning.
Should be rb_warn+assert_warn or rb_warning+assert_warning.

And non-default $; and $, are warned now.
Do you think these names should be warned too?

[jeremyevans0 (Jeremy Evans)]

• File warn-5-gvars-v2.patch warn-5-gvars-v2.patch added

nobu (Nobuyoshi Nakada) wrote:

It does not match to test rb_warn with assert_warning.
Should be rb_warn+assert_warn or rb_warning+assert_warning.

Thanks. I switched to assert_warn, as I think deprecation warnings should be a regular warning, not a verbose warning. Verbose warnings are best used for warnings like unused variables. I only think verbose deprecation warnings should be used if there is a plan to follow it up with a non-verbose deprecation warning before removing it.

And non-default $; and $, are warned now.
Do you think these names should be warned too?

I don't feel strongly about it. The $; and $, are currently run-time warnings based on the specific values passed when setting the values. akr's previous comment indicated that the warnings of the five variables should be at compile time.

One problem with the implementation in my previous patch is that it warns at the wrong location. Switching from rb_warn to rb_compile_warn fixes that issue.

Attached is an updated patch, as well as a few fixes where the global variables are currently used. Another file where they are also currently used is in:

/path/ruby/lib/rubygems/stub_specification.rb:114: warning: global variable $. is deprecated
/path/ruby/lib/rubygems/stub_specification.rb:134: warning: global variable $. is deprecated

But a fix there should be filed upstream.

There are probably additional cases where these global variables are used internally. At the very least all tests that use them probably need modification to hide the warnings.

[nobu (Nobuyoshi Nakada)]

jeremyevans0 (Jeremy Evans) wrote:

And non-default $; and $, are warned now.
Do you think these names should be warned too?

I don't feel strongly about it. The $; and $, are currently run-time warnings based on the specific values passed when setting the values. akr's previous comment indicated that the warnings of the five variables should be at compile time.

There are tons of that warnings, and it is not easy to suppress parser warning within the given file only.

One problem with the implementation in my previous patch is that it warns at the wrong location. Switching from rb_warn to rb_compile_warn fixes that issue.

It should be rb_warn1 and WARN_I(c) for ripper.
And a typo f.line_no in template/encdb.h.tmpl.

[jeremyevans0 (Jeremy Evans)]

• File warn-5-gvars-v3.patch warn-5-gvars-v3.patch added

nobu (Nobuyoshi Nakada) wrote:

jeremyevans0 (Jeremy Evans) wrote:

And non-default $; and $, are warned now.
Do you think these names should be warned too?

I don't feel strongly about it. The $; and $, are currently run-time warnings based on the specific values passed when setting the values. akr's previous comment indicated that the warnings of the five variables should be at compile time.

There are tons of that warnings, and it is not easy to suppress parser warning within the given file only.

Agreed. I'm fine dropping these compile warnings if the run-time warnings are considered sufficient.

One problem with the implementation in my previous patch is that it warns at the wrong location. Switching from rb_warn to rb_compile_warn fixes that issue.

It should be rb_warn1 and WARN_I(c) for ripper.
And a typo f.line_no in template/encdb.h.tmpl.

Thanks for the review. Attached is an updated patch that fixes these issues.

[nobu (Nobuyoshi Nakada)]

jeremyevans0 (Jeremy Evans) wrote:

nobu (Nobuyoshi Nakada) wrote:

jeremyevans0 (Jeremy Evans) wrote:

And non-default $; and $, are warned now.
Do you think these names should be warned too?

I don't feel strongly about it. The $; and $, are currently run-time warnings based on the specific values passed when setting the values. akr's previous comment indicated that the warnings of the five variables should be at compile time.

There are tons of that warnings, and it is not easy to suppress parser warning within the given file only.

Agreed. I'm fine dropping these compile warnings if the run-time warnings are considered sufficient.

Another point is that compile warnings are for the names.
Use of aliases of them like English.rb will be still silent.

So, this question.

Should we warn these four variable names, or their features?

[mame (Yusuke Endoh)]

• Tracker changed from Bug to Feature
• Backport deleted (2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN)

[mame (Yusuke Endoh)]

• Assignee set to jeremyevans0 (Jeremy Evans)
• Target version set to 36

At the previous dev meeting, matz said that it should display a warning dynamically, i.e., not at the parsing time but when the variables are assigned. Variable aliases should be also warned. @jeremyevans0 (Jeremy Evans), could you please progress?

• Status changed from Open to Closed

Applied in changeset git|9f99760dafac6eaa53287470b8ff59b1be0bf6d6.

---

Get rid of use of special variables

Use "\n" and IO#fileno instead of $/ and $. respectively.
[Feature #14240]

[nobu (Nobuyoshi Nakada)]

• Status changed from Closed to Open

[nobu (Nobuyoshi Nakada)]

• Status changed from Open to Closed

Applied in changeset git|6298ec2875a6f1a1e75698c96ceac94362f20bcf.

---

Warn non-nil $\ [Feature #14240]

[hsbt (Hiroshi SHIBATA)]

• Target version changed from 36 to 3.0