Project

General

Profile

Actions

Feature #14240

closed

warn four special variables: $; $, $/ $\

Added by akr (Akira Tanaka) almost 7 years ago. Updated about 4 years ago.

Status:
Closed
Target version:
[ruby-dev:50393]

Description

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).


Files

warn-5-gvars.patch (2.31 KB) warn-5-gvars.patch jeremyevans0 (Jeremy Evans), 07/26/2019 11:15 PM
warn-5-gvars-v2.patch (5.44 KB) warn-5-gvars-v2.patch jeremyevans0 (Jeremy Evans), 07/29/2019 07:03 PM
warn-5-gvars-v3.patch (5.4 KB) warn-5-gvars-v3.patch jeremyevans0 (Jeremy Evans), 08/26/2019 12:57 AM

Related issues 2 (0 open2 closed)

Related to Ruby master - Feature #14138: Define English.rb aliases by default and eliminate the libraryClosedActions
Related to Ruby master - Feature #5977: Remove $, and avoid perlish global variablesRejected02/07/2012Actions
Actions #1

Updated by matz (Yukihiro Matsumoto) almost 7 years ago

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

Updated by matz (Yukihiro Matsumoto) almost 7 years ago

Agreed.

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

Matz.

Updated by normalperson (Eric Wong) almost 7 years ago

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

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 :>

Updated by normalperson (Eric Wong) almost 7 years ago

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

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 :>

Updated by akr (Akira Tanaka) almost 7 years ago

2017-12-26 17:55 GMT+09:00 Eric Wong :

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

Updated by akr (Akira Tanaka) almost 7 years ago

2017-12-26 17:55 GMT+09:00 Eric Wong :

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

Updated by shevegen (Robert A. Heiler) almost 7 years ago

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.

Updated by normalperson (Eric Wong) almost 7 years ago

Tanaka Akira wrote:

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

2017-12-26 17:55 GMT+09:00 Eric Wong :

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.

Updated by normalperson (Eric Wong) almost 7 years ago

Tanaka Akira wrote:

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

2017-12-26 17:55 GMT+09:00 Eric Wong :

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.

Updated by Eregon (Benoit Daloze) almost 7 years ago

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.

Actions #11

Updated by Eregon (Benoit Daloze) almost 7 years ago

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

Updated by akr (Akira Tanaka) almost 7 years ago

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.

Updated by nobu (Nobuyoshi Nakada) almost 7 years ago

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?

Updated by jeremyevans0 (Jeremy Evans) over 5 years ago

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.

Updated by nobu (Nobuyoshi Nakada) over 5 years ago

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?

Updated by jeremyevans0 (Jeremy Evans) over 5 years ago

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.

Updated by nobu (Nobuyoshi Nakada) over 5 years ago

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.

Updated by jeremyevans0 (Jeremy Evans) about 5 years ago

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.

Updated by nobu (Nobuyoshi Nakada) about 5 years ago

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?

Actions #20

Updated by mame (Yusuke Endoh) almost 5 years ago

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

Updated by mame (Yusuke Endoh) almost 5 years ago

  • 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?

Actions #22

Updated by jeremyevans (Jeremy Evans) almost 5 years ago

  • 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]

Actions #23

Updated by nobu (Nobuyoshi Nakada) almost 5 years ago

  • Status changed from Closed to Open
Actions #24

Updated by nobu (Nobuyoshi Nakada) over 4 years ago

  • Status changed from Open to Closed

Applied in changeset git|6298ec2875a6f1a1e75698c96ceac94362f20bcf.


Warn non-nil $\ [Feature #14240]

Actions #25

Updated by hsbt (Hiroshi SHIBATA) about 4 years ago

  • Target version changed from 36 to 3.0
Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0Like0