[ruby-core:103132] [Ruby master Bug#17767] `Cloned ENV` inconsistently returns `ENV` or `self`

[ruby-core:103132] [Ruby master Bug#17767] `Cloned ENV` inconsistently returns `ENV` or `self`

[kachick1]

Issue #17767 has been reported by kachick (Kenichi Kamiya).

----------------------------------------
Bug #17767: `Cloned ENV` inconsistently returns `ENV` or `self`
https://bugs.ruby-lang.org/issues/17767

* Author: kachick (Kenichi Kamiya)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
GH-PR: https://github.com/ruby/ruby/pull/4344

Is this an expected behavior? 😅 

```console
$ ruby -v
ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
```

```ruby
cloned_env = ENV.clone

p ENV.each_key{}.equal?(ENV) #=> true
p cloned_env.each_key{}.equal?(cloned_env) #=> true

ENV.delete('TEST')

err = ENV.fetch('TEST') rescue $!
p err.receiver.equal?(ENV) #=> true
err = cloned_env.fetch('TEST') rescue $!
p err.receiver.equal?(cloned_env) #=> false

ENV['TEST'] = 'TRUE'
p ENV.select!{ false }.equal?(ENV) #=> true

cloned_env['TEST'] = 'TRUE'
p cloned_env.select!{ false }.equal?(cloned_env) #=> false
```

I guess ruby don't care `Cloned ENV` objects.
Yes, anyone basically do not write these code.
But the behaviors looks weird to me. 😓 

Should block to clone?
Should return ENV?
Should return self?

I think `they return self` makes consistently behaviors and does not break compatibilities.
So I have created this PR 😅 



-- 
https://bugs.ruby-lang.org/

[ruby-core:103192] [Ruby master Bug#17767] `Cloned ENV` inconsistently returns `ENV` or `self`

[merch-redmine]

Issue #17767 has been updated by jeremyevans0 (Jeremy Evans).


I don't think it makes sense to have cloned ENV objects. I propose the following behavior:

* `ENV.dup`/`ENV.clone`/`ENV.clone(freeze: nil)`/`ENV.clone(freeze: false)` should return `ENV`, since the same  singleton storage is used (the environ table). 
* `ENV.clone(freeze: true)` should raise `TypeError`, the same as `ENV.freeze`.
 
`ENV.dup` previously returned a useless instance of `Object`, since all `ENV` behavior is defined on a singleton class.

I've submitted a pull request implementing this proposal: https://github.com/ruby/ruby/pull/4350

----------------------------------------
Bug #17767: `Cloned ENV` inconsistently returns `ENV` or `self`
https://bugs.ruby-lang.org/issues/17767#change-91267

* Author: kachick (Kenichi Kamiya)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
GH-PR: https://github.com/ruby/ruby/pull/4344

Is this an expected behavior? 😅 

```console
$ ruby -v
ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
```

```ruby
cloned_env = ENV.clone

p ENV.each_key{}.equal?(ENV) #=> true
p cloned_env.each_key{}.equal?(cloned_env) #=> true

ENV.delete('TEST')

err = ENV.fetch('TEST') rescue $!
p err.receiver.equal?(ENV) #=> true
err = cloned_env.fetch('TEST') rescue $!
p err.receiver.equal?(cloned_env) #=> false

ENV['TEST'] = 'TRUE'
p ENV.select!{ false }.equal?(ENV) #=> true

cloned_env['TEST'] = 'TRUE'
p cloned_env.select!{ false }.equal?(cloned_env) #=> false
```

I guess ruby don't care `Cloned ENV` objects.
Yes, anyone basically do not write these code.
But the behaviors looks weird to me. 😓 

Should block to clone?
Should return ENV?
Should return self?

I think `they return self` makes consistently behaviors and does not break compatibilities.
So I have created this PR 😅 



-- 
https://bugs.ruby-lang.org/

[ruby-core:103195] [Ruby master Bug#17767] `Cloned ENV` inconsistently returns `ENV` or `self`

[nobu]

Issue #17767 has been updated by nobu (Nobuyoshi Nakada).


jeremyevans0 (Jeremy Evans) wrote in #note-1:
> I don't think it makes sense to have cloned ENV objects.

It feels reasonable.

----------------------------------------
Bug #17767: `Cloned ENV` inconsistently returns `ENV` or `self`
https://bugs.ruby-lang.org/issues/17767#change-91271

* Author: kachick (Kenichi Kamiya)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
GH-PR: https://github.com/ruby/ruby/pull/4344

Is this an expected behavior? 😅 

```console
$ ruby -v
ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
```

```ruby
cloned_env = ENV.clone

p ENV.each_key{}.equal?(ENV) #=> true
p cloned_env.each_key{}.equal?(cloned_env) #=> true

ENV.delete('TEST')

err = ENV.fetch('TEST') rescue $!
p err.receiver.equal?(ENV) #=> true
err = cloned_env.fetch('TEST') rescue $!
p err.receiver.equal?(cloned_env) #=> false

ENV['TEST'] = 'TRUE'
p ENV.select!{ false }.equal?(ENV) #=> true

cloned_env['TEST'] = 'TRUE'
p cloned_env.select!{ false }.equal?(cloned_env) #=> false
```

I guess ruby don't care `Cloned ENV` objects.
Yes, anyone basically do not write these code.
But the behaviors looks weird to me. 😓 

Should block to clone?
Should return ENV?
Should return self?

I think `they return self` makes consistently behaviors and does not break compatibilities.
So I have created this PR 😅 



-- 
https://bugs.ruby-lang.org/

[ruby-core:103908] [Ruby master Bug#17767] `Cloned ENV` inconsistently returns `ENV` or `self`

[nobu]

Issue #17767 has been updated by nobu (Nobuyoshi Nakada).


Cloned `ENV` accesses/modifies the process global environment variables, as well as `ENV` itself, however the codes we found expect these are different.
So I propose `ENV.clone` and `ENV.dup` should raise an exception.

----------------------------------------
Bug #17767: `Cloned ENV` inconsistently returns `ENV` or `self`
https://bugs.ruby-lang.org/issues/17767#change-92037

* Author: kachick (Kenichi Kamiya)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
GH-PR: https://github.com/ruby/ruby/pull/4344

Is this an expected behavior? 😅 

```console
$ ruby -v
ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
```

```ruby
cloned_env = ENV.clone

p ENV.each_key{}.equal?(ENV) #=> true
p cloned_env.each_key{}.equal?(cloned_env) #=> true

ENV.delete('TEST')

err = ENV.fetch('TEST') rescue $!
p err.receiver.equal?(ENV) #=> true
err = cloned_env.fetch('TEST') rescue $!
p err.receiver.equal?(cloned_env) #=> false

ENV['TEST'] = 'TRUE'
p ENV.select!{ false }.equal?(ENV) #=> true

cloned_env['TEST'] = 'TRUE'
p cloned_env.select!{ false }.equal?(cloned_env) #=> false
```

I guess ruby don't care `Cloned ENV` objects.
Yes, anyone basically do not write these code.
But the behaviors looks weird to me. 😓 

Should block to clone?
Should return ENV?
Should return self?

I think `they return self` makes consistently behaviors and does not break compatibilities.
So I have created this PR 😅 



-- 
https://bugs.ruby-lang.org/

[ruby-core:104195] [Ruby master Bug#17767] `Cloned ENV` inconsistently returns `ENV` or `self`

[merch-redmine]

Issue #17767 has been updated by jeremyevans0 (Jeremy Evans).


At the May 2021 developer meeting, it was decided that `ENV.dup` should raise and `ENV.clone` should warn, so I closed my previous pull request and added a pull request for that behavior: https://github.com/ruby/ruby/pull/4557

----------------------------------------
Bug #17767: `Cloned ENV` inconsistently returns `ENV` or `self`
https://bugs.ruby-lang.org/issues/17767#change-92375

* Author: kachick (Kenichi Kamiya)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
GH-PR: https://github.com/ruby/ruby/pull/4344

Is this an expected behavior? 😅 

```console
$ ruby -v
ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
```

```ruby
cloned_env = ENV.clone

p ENV.each_key{}.equal?(ENV) #=> true
p cloned_env.each_key{}.equal?(cloned_env) #=> true

ENV.delete('TEST')

err = ENV.fetch('TEST') rescue $!
p err.receiver.equal?(ENV) #=> true
err = cloned_env.fetch('TEST') rescue $!
p err.receiver.equal?(cloned_env) #=> false

ENV['TEST'] = 'TRUE'
p ENV.select!{ false }.equal?(ENV) #=> true

cloned_env['TEST'] = 'TRUE'
p cloned_env.select!{ false }.equal?(cloned_env) #=> false
```

I guess ruby don't care `Cloned ENV` objects.
Yes, anyone basically do not write these code.
But the behaviors looks weird to me. 😓 

Should block to clone?
Should return ENV?
Should return self?

I think `they return self` makes consistently behaviors and does not break compatibilities.
So I have created this PR 😅 



-- 
https://bugs.ruby-lang.org/

[ruby-core:109263] [Ruby master Bug#17767] `Cloned ENV` inconsistently returns `ENV` or `self`

[nobu (Nobuyoshi Nakada)]

Issue #17767 has been updated by nobu (Nobuyoshi Nakada).


Now can/should we make `ENV.clone` an error too?


----------------------------------------
Bug #17767: `Cloned ENV` inconsistently returns `ENV` or `self`
https://bugs.ruby-lang.org/issues/17767#change-98396

* Author: kachick (Kenichi Kamiya)
* Status: Closed
* Priority: Normal
* ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
GH-PR: https://github.com/ruby/ruby/pull/4344

Is this an expected behavior? 😅 

```console
$ ruby -v
ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
```

```ruby
cloned_env = ENV.clone

p ENV.each_key{}.equal?(ENV) #=> true
p cloned_env.each_key{}.equal?(cloned_env) #=> true

ENV.delete('TEST')

err = ENV.fetch('TEST') rescue $!
p err.receiver.equal?(ENV) #=> true
err = cloned_env.fetch('TEST') rescue $!
p err.receiver.equal?(cloned_env) #=> false

ENV['TEST'] = 'TRUE'
p ENV.select!{ false }.equal?(ENV) #=> true

cloned_env['TEST'] = 'TRUE'
p cloned_env.select!{ false }.equal?(cloned_env) #=> false
```

I guess ruby don't care `Cloned ENV` objects.
Yes, anyone basically do not write these code.
But the behaviors looks weird to me. 😓 

Should block to clone?
Should return ENV?
Should return self?

I think `they return self` makes consistently behaviors and does not break compatibilities.
So I have created this PR 😅 



-- 
https://bugs.ruby-lang.org/

[ruby-core:109799] [Ruby master Bug#17767] `Cloned ENV` inconsistently returns `ENV` or `self`

[Dan0042 (Daniel DeLorme)]

Issue #17767 has been updated by Dan0042 (Daniel DeLorme).


I realize I'm late, but instead of "pointing the user to use ENV.to_h" it would be more helpful to just have dup/clone be aliases of to_h. It's the obvious behavior that everyone using ENV.clone was expecting in the first place.

----------------------------------------
Bug #17767: `Cloned ENV` inconsistently returns `ENV` or `self`
https://bugs.ruby-lang.org/issues/17767#change-99040

* Author: kachick (Kenichi Kamiya)
* Status: Closed
* Priority: Normal
* ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
GH-PR: https://github.com/ruby/ruby/pull/4344

Is this an expected behavior? 😅 

```console
$ ruby -v
ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
```

```ruby
cloned_env = ENV.clone

p ENV.each_key{}.equal?(ENV) #=> true
p cloned_env.each_key{}.equal?(cloned_env) #=> true

ENV.delete('TEST')

err = ENV.fetch('TEST') rescue $!
p err.receiver.equal?(ENV) #=> true
err = cloned_env.fetch('TEST') rescue $!
p err.receiver.equal?(cloned_env) #=> false

ENV['TEST'] = 'TRUE'
p ENV.select!{ false }.equal?(ENV) #=> true

cloned_env['TEST'] = 'TRUE'
p cloned_env.select!{ false }.equal?(cloned_env) #=> false
```

I guess ruby don't care `Cloned ENV` objects.
Yes, anyone basically do not write these code.
But the behaviors looks weird to me. 😓 

Should block to clone?
Should return ENV?
Should return self?

I think `they return self` makes consistently behaviors and does not break compatibilities.
So I have created this PR 😅 



-- 
https://bugs.ruby-lang.org/

[ruby-core:109825] [Ruby master Bug#17767] `Cloned ENV` inconsistently returns `ENV` or `self`

[nobu (Nobuyoshi Nakada)]

Issue #17767 has been updated by nobu (Nobuyoshi Nakada).


@Dan0042 It is not a "clone".




----------------------------------------
Bug #17767: `Cloned ENV` inconsistently returns `ENV` or `self`
https://bugs.ruby-lang.org/issues/17767#change-99064

* Author: kachick (Kenichi Kamiya)
* Status: Closed
* Priority: Normal
* ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN
----------------------------------------
GH-PR: https://github.com/ruby/ruby/pull/4344

Is this an expected behavior? 😅 

```console
$ ruby -v
ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
```

```ruby
cloned_env = ENV.clone

p ENV.each_key{}.equal?(ENV) #=> true
p cloned_env.each_key{}.equal?(cloned_env) #=> true

ENV.delete('TEST')

err = ENV.fetch('TEST') rescue $!
p err.receiver.equal?(ENV) #=> true
err = cloned_env.fetch('TEST') rescue $!
p err.receiver.equal?(cloned_env) #=> false

ENV['TEST'] = 'TRUE'
p ENV.select!{ false }.equal?(ENV) #=> true

cloned_env['TEST'] = 'TRUE'
p cloned_env.select!{ false }.equal?(cloned_env) #=> false
```

I guess ruby don't care `Cloned ENV` objects.
Yes, anyone basically do not write these code.
But the behaviors looks weird to me. 😓 

Should block to clone?
Should return ENV?
Should return self?

I think `they return self` makes consistently behaviors and does not break compatibilities.
So I have created this PR 😅 



-- 
https://bugs.ruby-lang.org/