Feature #19036: Provide a way to set path for File instances created with for_fd

• Status: Closed
• Assignee: -
• Target version: -

[headius (Charles Nutter)]

Ruby provides IO.for_fd to instantiate an IO object from an existing file descriptor value. The logic for this simply calls the base IO.new logic, which for all IO and subtypes simply wraps the given file descriptor.

When called against File, or other subtypes of IO, this has the side effect of creating an IO instance with that type, e.g. File.for_fd will behave identically to IO.for_fd except that the class of the resulting object will be File.

Unfortunately, this results in a File object that does not have any path associated with it:

3.1.2 :001 > f = File.open('README.md')
 => #<File:README.md> 
3.1.2 :002 > f.path
 => "README.md" 
3.1.2 :003 > f2 = File.for_fd(f.fileno)
 => #<File:fd 5> 
3.1.2 :004 > f2.path
(irb):4:in `path': File is unnamed (TMPFILE?) (IOError)
        from (irb):4:in `<main>'                                
        from /home/headius/.rvm/rubies/ruby-3.1.2/lib/ruby/gems/3.1.0/gems/irb-1.4.1/exe/irb:11:in `<top (required)>'
        from /home/headius/.rvm/rubies/ruby-3.1.2/bin/irb:25:in `load'
        from /home/headius/.rvm/rubies/ruby-3.1.2/bin/irb:25:in `<main>'

I propose that there should be a way, via an extra parameter or a keyword argument, to provide a path when constructing a new File via for_fd.

Possible forms:

• File.for_fd(fileno, "my/path")
• File.for_fd(fileno, path: "my/path")

This would necessitate a separate implementation for File.for_fd unless we want to make it possible to set a path for all for_fd calls (which may not make sense for many of them).

This came up while trying to implement a pure-Ruby (plus FFI) version of the "pty" library. Without overriding the path function, it is not possible for the File object returned by PTY.open to gain the "masterpty:" filename, and therefore it does not clearly indicate it is from a PTY.

See https://github.com/jruby/jruby/pull/7391, an attempt to match inspect output for these return values using define_singleton_method. Providing a way to set the path would make this automatic without the singleton definition.

[headius (Charles Nutter)]

Looking at the linked PR again I realize that we would need this functionality for IO as well, in order for the IO object to have the "masterpty" marker. The File would still need help, so we can for_fd but provide the slave name as path.

[mame (Yusuke Endoh)]

• Target version deleted (3.2)

[ko1 (Koichi Sasada)]

It seems okay for File.for_fd(fd, path: ...) but I'm not sure IO.for_fd(fd, path: ...). Maybe it affects only #inspect because IO#path is not defined.

I think this functionality is also useful to label known IO such as:

p STDERR
#=> #<IO:<STDERR>>

p IO.for_fd(STDERR.to_i)
#<IO:fd 2>

p IO.for_fd(STDERR.to_i, path: '<STDERR>')
#=> #<IO:<STDERR>>

name for strictly usage?

[ioquatix (Samuel Williams)]

Ruby IO is a rich object and has an internal path. It seems reasonable that IO.new or IO.for_fd can set it. I don't think this is something specific to File in the way Ruby thinks about IO.

[matz (Yukihiro Matsumoto)]

LGTM.

Matz.

[ioquatix (Samuel Williams)]

• Status changed from Open to Closed

Implemented in https://github.com/ruby/ruby/pull/6867.

Follow up discussion:

• Should we introduce IO#path=?
• Should we introduce IO#dup(..., path:)?

[Eregon (Benoit Daloze)]

ioquatix (Samuel Williams) wrote in #note-6:

Implemented in https://github.com/ruby/ruby/pull/6867.

Thanks!

Follow up discussion:

• Should we introduce IO#path=?

I think not, AFAIK there is no need for this to be mutable.

• Should we introduce IO#dup(..., path:)?

Definitely not worth the complexity, and dup doesn't have this general contract anyway.

[headius (Charles Nutter)]

Eregon (Benoit Daloze) wrote in #note-7:

• Should we introduce IO#path=?

I think not, AFAIK there is no need for this to be mutable.

Agree. Also briefly brainstormed some possible security issues with being able to mutate the path after init. Don't want to go there and don't really see a need.

• Should we introduce IO#dup(..., path:)?

Definitely not worth the complexity, and dup doesn't have this general contract anyway.

Agree.

Additional question: why is rb_io_path not part of the public C API? Luckily, rb_file_path wasn't either, but it seems like it would be useful to expose rb_io_path now.