[ruby-core:98920] [Ruby master Bug#16978] Ruby should not use realpath for __FILE__

[ruby-core:98920] [Ruby master Bug#16978] Ruby should not use realpath for __FILE__

[v.ondruch]

Issue #16978 has been reported by vo.x (Vit Ondruch).

----------------------------------------
Bug #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
* ruby -v: ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux]
* Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:99099] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[merch-redmine]

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

Backport deleted (2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN)
ruby -v deleted (ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux])
Tracker changed from Bug to Feature

I don't think this is a bug.  `__FILE__` is documented as follows: `The path to the current file.`  Which path (real, absolute, relative, expanded) is not specified.

Not using the real path would lead to behavior that depends on the first path used when requiring the file.

`a/test.rb` (`b` symlinked to `a`):

```ruby
def a
  __FILE__
end
```

```
ruby -Ia -Ib -rtest -e 'a'
# /path/to/a/test.rb
ruby -Ib -Ia -rtest -e 'a'
# Current: /path/to/a/test.rb
# Your proposed: /path/to/b/test.rb
```

What actually happens is not the file path being converted to a real path, but the include directory being converted to a real path before the file is required (in `rb_construct_expanded_load_path`).  Changing this to not use a real path would probably break the code that checks that a feature hasn't been require twice.  For example, this code would change behavior:

```
$: << 'a'
require 'test'
$: << 'b'
require 'test'
# Current: not loaded again
# Your proposed: loaded again
```

If you symlink the file itself and not the include directory, Ruby will attempt to require it as a separate feature.

Note that if you provide a path when requiring, Ruby already operates the way you want:

```
ruby -r./a/test -e 'a' # /path/to/a/test.rb
ruby -r./b/test -e 'a' # /path/to/b/test.rb
```

I can certainly see pros and cons from changing the behavior, but I would consider this a feature request and not a bug.

----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-86473

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:99101] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[eregontp]

Issue #16978 has been updated by Eregon (Benoit Daloze).


The "main file" (the file passed to `ruby myfile.rb` is also special in that `__FILE__` and `$0` can both be relative paths (basically the same path as passed on the command line).

----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-86475

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:99103] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[v.ondruch]

Issue #16978 has been updated by vo.x (Vit Ondruch).


> this code would change behavior:

Absolutely, different `$LOAD_PATH` must result in different behavior.

> ~~~
> $: << 'a'
> require 'test'
> $: << 'b'
> require 'test'
> # Current: not loaded again
> # Your proposed: loaded again
> ~~~

This is actually where I am coming from. I am not 100 % sure what is the spec of `require`, but I would expect that `require 'test'` works just once and it does not matter what is the current `$LOAD_PATH` status. So my proposal is actually:

~~~
# Your proposed: not loaded again
~~~

----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-86477

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:102194] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[v.ondruch]

Issue #16978 has been updated by vo.x (Vit Ondruch).


Can this be resolved please? This is another scenario, which should work IMO, but it does not work:

~~~
$ mkdir a/
$ echo "require_relative 'b'" > a/test.rb
$ touch b.rb

$ ll
total 4
drwxrwxr-x. 1 vondruch vondruch 14 Jan 22 17:17 a
-rw-rw-r--. 1 vondruch vondruch  0 Jan 22 17:17 b.rb
lrwxrwxrwx. 1 vondruch vondruch  9 Jan 22 17:18 test.rb -> a/test.rb

$ ruby test.rb
Traceback (most recent call last):
	1: from test.rb:1:in `<main>'
test.rb:1:in `require_relative': cannot load such file -- /home/vondruch/tt/a/b (LoadError)
~~~

The point is that in the context of current directory, the `b.rb` is relative to `test.rb` and therefore this example should not work. It does not really matter that the `test.rb` is symlink. This behavior with `requie_relative` being more and more common basically prohibits usage of symlinks for Ruby code.

This is issue because gems typically does not ship their test suites. Therefore when testing packages in Fedora, we would like do something like:

~~~
$ gem unpack rspec-rails
Fetching rspec-rails-4.0.2.gem
Unpacked gem: '/home/vondruch/tt/rspec-rails-4.0.2'

$ cd rspec-rails-4.0.2/

# Link from git checkout or from separate archive
$ ln -s ~/projects/rspec/rspec-rails/spec/ .
~~~

This blows out as soon as `require_relative` is used in test suite, because it cannot refer back to `require_relative "../lib/rspec_rails"`, which expands to `/home/vondruch/projects/rspec/rspec-rails/spec/../lib/rspec_rails`, where there is either loaded completely different file or nothing. In Fedora [1], the test suite is typically extracted from tarball, so this would crash.

[1]: https://src.fedoraproject.org/rpms/rubygem-rspec-rails/blob/master/f/rubygem-rspec-rails.spec#_78

----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-90041

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:102197] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[akr]

Issue #16978 has been updated by akr (Akira Tanaka).


I think we should use realpath.
The location of actual file is more robust.

Also, ELF dynamic linker has a feature, $ORIGIN, to refer a shared library using a relative path.
It also resolves symlinks.
https://refspecs.linuxbase.org/elf/gabi4+/ch5.dynamic.html



----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-90044

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:102199] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[daniel]

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


+1 for keeping the current behavior.

I remember in 1.8 we had so many problems with double-loading code because a file could be require'd with different paths. I have no wish to go back to that mess.

----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-90046

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:102200] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[v.ondruch]

Issue #16978 has been updated by vo.x (Vit Ondruch).


I have problem with double loading because of symlinks resolving into real path. If there was ensured that `require "foo"` load file just once, then double loading can't happen.

In Fedora, to avoid duplication, we have openssl gem extracted into independent package, which links back to the StdLib to keep the Ruby functionality. Unfortunately, since this commit [1], which introduces `require_relative`, we have issues with double loading. The simple reproducer is `ruby --disable-gems -e 'require "openssl"; require "openssl/digest"`.

You can admit that Fedora is doing something unexpected, but I think that the package split was done prior the `require_relative` was even introduced.


[1]: https://github.com/ruby/openssl/commit/74e03b588f58bcac007d7145c3bb6c4754daa1b0

----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-90047

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:102201] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[halostatue]

Issue #16978 has been updated by austin (Austin Ziegler).


Why not put some special handling in to `require_relative` such that it checks both the pre-`realpath` and `realpath` versions (perhaps behind a `#define` flow so that Fedora and other systems integrators can do this without impacting anyone else, assuming `require_relative` is in C) so that it can handle this case?

----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-90048

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:102209] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[daniel]

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


Interestingly, ruby does _not_ use realpath for `__FILE__`, only for `__dir__` and `require_relative`

```
$ cat test.rb
p __dir__ => __FILE__
require_relative "b"

$ cat a/b.rb
p __dir__ => __FILE__
require_relative "c"

$ ln -s a/b.rb

$ touch c.rb 

$ ruby test.rb
{"/home/dan42/16978"=>"test.rb"}
{"/home/dan42/16978/a"=>"/home/dan42/16978/b.rb"}
Traceback (most recent call last):
	3: from test.rb:2:in `<main>'
	2: from test.rb:2:in `require_relative'
	1: from /home/dan42/16978/b.rb:2:in `<top (required)>'
/home/dan42/16978/b.rb:2:in `require_relative': cannot load such file -- /home/dan42/16978/a/c (LoadError)
```

----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-90056

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:102214] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[eregontp]

Issue #16978 has been updated by Eregon (Benoit Daloze).


vo.x (Vit Ondruch) wrote in #note-7:
> In Fedora, to avoid duplication, we have openssl gem extracted into independent package, which links back to the StdLib to keep the Ruby functionality.

What does it look like on the filesystem?

Even if the package is split, the standard location could be used, no need for symlinks, isn't it?

----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-90061

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:102221] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[v.ondruch]

Issue #16978 has been updated by vo.x (Vit Ondruch).


Eregon (Benoit Daloze) wrote in #note-10:
> vo.x (Vit Ondruch) wrote in #note-7:
> > In Fedora, to avoid duplication, we have openssl gem extracted into independent package, which links back to the StdLib to keep the Ruby functionality.
> 
> What does it look like on the filesystem?

This is how it is constructed. Here is where the OpenSSL structure is created in traditional gem directories:

https://src.fedoraproject.org/rpms/ruby/blob/master/f/ruby.spec#_761

And here are the links back to the StdLib location:

https://src.fedoraproject.org/rpms/ruby/blob/master/f/ruby.spec#_771

> Even if the package is split, the standard location could be used, no need for symlinks, isn't it?

Not sure what do you mean specifically, because of course I'd prefer if there are no symlinks. The idea is that rubygem-openssl, should be replaced by newer version of openssl released on rubygems.org, without upgrading Ruby itself, therefore the files have to be located in the gem directory. Of course there are different possibilities, how to workaround that (e.g. #14737). The only question how sustainable they are.

However, Fedora is orthogonal and just distraction to this issue, because I can imagine if I were ruby openssl developer, I'd like to replace content of Ruby build with my development version of OpenSSL from git snapshot via symlinks, e.g.:

~~~
$ cd ~
$ git clone https://github.com/ruby/openssl.git
# rm /usr/local/lib/ruby/3.0.0/openssl*
# ln -s ~/openssl/lib/openssl.rb .
# ln -s ~/openssl/lib/openssl .
$ /usr/local/bin/ruby --disable-gems -e 'require "openssl"; require "openssl/digest"'
/usr/local/lib/ruby/3.0.0/openssl/digest.rb:45: warning: already initialized constant OpenSSL::Digest::MD4
/builddir/openssl/lib/openssl/digest.rb:45: warning: previous definition of MD4 was here
/usr/local/lib/ruby/3.0.0/openssl/digest.rb:45: warning: already initialized constant OpenSSL::Digest::MD5
/builddir/openssl/lib/openssl/digest.rb:45: warning: previous definition of MD5 was here
/usr/local/lib/ruby/3.0.0/openssl/digest.rb:45: warning: already initialized constant OpenSSL::Digest::RIPEMD160
/builddir/openssl/lib/openssl/digest.rb:45: warning: previous definition of RIPEMD160 was here
/usr/local/lib/ruby/3.0.0/openssl/digest.rb:45: warning: already initialized constant OpenSSL::Digest::SHA1
/builddir/openssl/lib/openssl/digest.rb:45: warning: previous definition of SHA1 was here
/usr/local/lib/ruby/3.0.0/openssl/digest.rb:45: warning: already initialized constant OpenSSL::Digest::SHA224
/builddir/openssl/lib/openssl/digest.rb:45: warning: previous definition of SHA224 was here
/usr/local/lib/ruby/3.0.0/openssl/digest.rb:45: warning: already initialized constant OpenSSL::Digest::SHA256
/builddir/openssl/lib/openssl/digest.rb:45: warning: previous definition of SHA256 was here
/usr/local/lib/ruby/3.0.0/openssl/digest.rb:45: warning: already initialized constant OpenSSL::Digest::SHA384
/builddir/openssl/lib/openssl/digest.rb:45: warning: previous definition of SHA384 was here
/usr/local/lib/ruby/3.0.0/openssl/digest.rb:45: warning: already initialized constant OpenSSL::Digest::SHA512
/builddir/openssl/lib/openssl/digest.rb:45: warning: previous definition of SHA512 was here
/usr/local/lib/ruby/3.0.0/openssl/digest.rb:52:in `<class:Digest>': superclass mismatch for class Digest (TypeError)
	from /usr/local/lib/ruby/3.0.0/openssl/digest.rb:16:in `<module:OpenSSL>'
	from /usr/local/lib/ruby/3.0.0/openssl/digest.rb:15:in `<top (required)>'
	from -e:1:in `require'
	from -e:1:in `<main>'
~~~

Everybody can try the example above? Is it artificial and should be prohibited? Should it fail?

----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-90069

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:102234] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[daniel]

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


I think this is a bug and should be fixed, but IMO the proper fix is to use realpath for `__FILE__`

So in the example above when you do `require "openssl/digest"`, ruby will find `/usr/local/lib/ruby/3.0.0/openssl/digest.rb` and then it should check the realpath (`~/openssl/lib/openssl/digest.rb`) before loading the file.


----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-90084

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:102239] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[v.ondruch]

Issue #16978 has been updated by vo.x (Vit Ondruch).


Dan0042 (Daniel DeLorme) wrote in #note-12:
> I think this is a bug and should be fixed, but IMO the proper fix is to use realpath for `__FILE__`

This is though one thinking about this again, but you are probably right. Maybe the biggest concern is that the behavior is inconsistent. If the `require` and `__FILE__` used `realpath`, I think the example in #16978-11 would work as you said.



----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-90089

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:102865] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[ko1]

Issue #16978 has been updated by ko1 (Koichi Sasada).

Assignee set to nobu (Nobuyoshi Nakada)

----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-90924

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
* Assignee: nobu (Nobuyoshi Nakada)
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:104429] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[merch-redmine]

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


vo.x (Vit Ondruch) wrote in #note-13:
> Dan0042 (Daniel DeLorme) wrote in #note-12:
> > I think this is a bug and should be fixed, but IMO the proper fix is to use realpath for `__FILE__`
> 
> This is though one thinking about this again, but you are probably right. Maybe the biggest concern is that the behavior is inconsistent. If the `require` and `__FILE__` used `realpath`, I think the example in #16978-11 would work as you said.

It's not difficult to make `__FILE__` use `realpath`:

```diff
@@ -10307,6 +10307,14 @@ numparam_nested_p(struct parser_params *p)
     return 0;
 }

+VALUE rb_realpath_internal(VALUE basedir, VALUE path, int strict);
+
+static VALUE
+rb_realpath__FILE__(VALUE file)
+{
+    return rb_realpath_internal(Qnil, file, 1);
+}
+
 static NODE*
 gettable(struct parser_params *p, ID id, const YYLTYPE *loc)
 {
@@ -10326,8 +10334,19 @@ gettable(struct parser_params *p, ID id, const YYLTYPE *loc)
            VALUE file = p->ruby_sourcefile_string;
            if (NIL_P(file))
                file = rb_str_new(0, 0);
-           else
-               file = rb_str_dup(file);
+           else if (compile_for_eval) {
+                file = rb_str_dup(file);
+            }
+           else {
+                int state;
+               VALUE realpath_file = rb_protect(rb_realpath__FILE__, file, &state);
+                if (state) {
+                    file = rb_str_dup(file);
+                }
+                else {
+                    file = realpath_file;
+                }
+            }
            node = NEW_STR(file, loc);
             RB_OBJ_WRITTEN(p->ast, Qnil, file);
        }
```

Unfortunately, if `__FILE__` uses `realpath`, unless you also change the behavior of `$0` (which I'm fairly sure would not be acceptable), you break the common idiom for executing code if the file is executed instead of required:

```ruby
if __FILE__ == $0
  do_something
end
```



----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-92682

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
* Assignee: nobu (Nobuyoshi Nakada)
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:104434] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[jean.boussier]

Issue #16978 has been updated by byroot (Jean Boussier).


> Unfortunately, if __FILE__ uses realpath, unless you also change the behavior of $0 

The "entrypoint" script could behave differently, but maybe that would be confusing.

----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-92688

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
* Assignee: nobu (Nobuyoshi Nakada)
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:104454] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[daniel]

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


byroot (Jean Boussier) wrote in #note-17:
> The "entrypoint" script could behave differently, but maybe that would be confusing.

I think that would be acceptable. After all the "entrypoint" script already behaves differently; it's the only one where __FILE__ is not always an absolute path.

----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-92709

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
* Assignee: nobu (Nobuyoshi Nakada)
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:104458] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[jean.boussier]

Issue #16978 has been updated by byroot (Jean Boussier).


This issue seems also somewhat related to another I opened a while ago: #17593 

----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-92713

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
* Assignee: nobu (Nobuyoshi Nakada)
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:104508] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[daniel]

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


jeremyevans0 (Jeremy Evans) wrote in #note-16:
> It's not difficult to make `__FILE__` use `realpath`

I read this once more a bit more carefully and I think there's a misunderstanding... the idea here is that realpath should be used in `require` _before_ checking if the file is already loaded (and then loading it). So `p->ruby_sourcefile_string` would already be the realpath.


----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-92778

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
* Assignee: nobu (Nobuyoshi Nakada)
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:104510] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[merch-redmine]

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


Dan0042 (Daniel DeLorme) wrote in #note-20:
> jeremyevans0 (Jeremy Evans) wrote in #note-16:
> > It's not difficult to make `__FILE__` use `realpath`
> 
> I read this once more a bit more carefully and I think there's a misunderstanding... the idea here is that realpath should be used in `require` _before_ checking if the file is already loaded (and then loading it). So `p->ruby_sourcefile_string` would already be the realpath.

I tried that approach first when working on #17885.  It doesn't work because the loaded feature index is designed around load paths and not real paths.  You would have to rewrite the loaded feature index and its interaction with autoload to switch to that approach.

----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-92780

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
* Assignee: nobu (Nobuyoshi Nakada)
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:106605] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[vo.x (Vit Ondruch)]

Issue #16978 has been updated by vo.x (Vit Ondruch).


I wonder what is the situation here given that the #17885 seems to be resolved?

----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-95274

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
* Assignee: nobu (Nobuyoshi Nakada)
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:108143] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[retro]

Issue #16978 has been updated by retro (Josef Šimánek).


We have hit this problem as well in rubygems and it is really unexpected and confusing.

https://github.com/rubygems/rubygems/pull/5437

TL;DR; test passes calling `rake test`, but not using `ruby -I... test/file.rb`

----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-97119

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
* Assignee: nobu (Nobuyoshi Nakada)
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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

[ruby-core:108153] [Ruby master Feature#16978] Ruby should not use realpath for __FILE__

[retro]

Issue #16978 has been updated by retro (Josef Šimánek).


In the end RubyGems decided to leave `__FILE__` due to this behaviour at all. If I understand Jeremy's original reasoning well, it was actually misused. Anyway it would be great to inline `__FILE__` and `__dir__` to provide consistent output.  https://github.com/rubygems/rubygems/pull/5444

----------------------------------------
Feature #16978: Ruby should not use realpath for __FILE__
https://bugs.ruby-lang.org/issues/16978#change-97128

* Author: vo.x (Vit Ondruch)
* Status: Open
* Priority: Normal
* Assignee: nobu (Nobuyoshi Nakada)
----------------------------------------
This is the simplest test case:

~~~
$ mkdir a

$ echo "puts __FILE__" > a/test.rb

$ ln -s a b

$ ruby -Ib -e "require 'test'"
/builddir/a/test.rb
~~~

This behavior is problematic, because Ruby should not know nothing about the `a` directory. It was not instructed to use it. I should always refer to the file using the original path and do not dig into the underlying details, otherwise depending on file system setup, one might be forced to used `File.realpath` everywhere trying to use `__FILE__`.



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