Project

General

Profile

Bug #14240

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

Added by akr (Akira Tanaka) 10 months ago. Updated 9 months ago.

Status:
Open
Priority:
Normal
Assignee:
-
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).


Related issues

Related to Ruby trunk - Feature #14138: Define English.rb aliases by default and eliminate the libraryClosed
Related to Ruby trunk - Feature #5977: Remove $, and avoid perlish global variablesRejected2012-02-07

History

#1 Updated by matz (Yukihiro Matsumoto) 10 months ago

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

#2 [ruby-dev:50394] Updated by matz (Yukihiro Matsumoto) 10 months ago

Agreed.

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

Matz.

#3 [ruby-core:84472] Updated by normalperson (Eric Wong) 10 months ago

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

matz@ruby-lang.org 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 :>

#4 [ruby-dev:50396] Updated by normalperson (Eric Wong) 10 months ago

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

matz@ruby-lang.org 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 :>

#5 [ruby-core:84476] Updated by akr (Akira Tanaka) 10 months ago

2017-12-26 17:55 GMT+09:00 Eric Wong normalperson@yhbt.net:

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

#6 [ruby-dev:50397] Updated by akr (Akira Tanaka) 10 months ago

2017-12-26 17:55 GMT+09:00 Eric Wong normalperson@yhbt.net:

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

#7 [ruby-dev:50398] Updated by shevegen (Robert A. Heiler) 10 months 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.

#8 [ruby-core:84486] Updated by normalperson (Eric Wong) 10 months ago

Tanaka Akira akr@fsij.org wrote:

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

2017-12-26 17:55 GMT+09:00 Eric Wong normalperson@yhbt.net:

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.

#9 [ruby-dev:50400] Updated by normalperson (Eric Wong) 10 months ago

Tanaka Akira akr@fsij.org wrote:

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

2017-12-26 17:55 GMT+09:00 Eric Wong normalperson@yhbt.net:

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.

#10 [ruby-dev:50401] Updated by Eregon (Benoit Daloze) 10 months 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.

#11 Updated by Eregon (Benoit Daloze) 10 months ago

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

#12 [ruby-dev:50425] Updated by akr (Akira Tanaka) 9 months 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.

#13 [ruby-dev:50431] Updated by nobu (Nobuyoshi Nakada) 9 months 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?

Also available in: Atom PDF