Project

General

Profile

Actions

Feature #19036

closed

Provide a way to set path for File instances created with for_fd

Added by headius (Charles Nutter) over 1 year ago. Updated over 1 year ago.

Status:
Closed
Assignee:
-
Target version:
-
[ruby-core:<unknown>]

Description

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.

Actions #1

Updated by headius (Charles Nutter) over 1 year ago

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.

Actions #2

Updated by mame (Yusuke Endoh) over 1 year ago

  • Target version deleted (3.2)

Updated by ko1 (Koichi Sasada) over 1 year ago

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?

Updated by ioquatix (Samuel Williams) over 1 year ago

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.

Updated by ioquatix (Samuel Williams) over 1 year ago

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

Updated by Eregon (Benoit Daloze) over 1 year ago

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.

Updated by headius (Charles Nutter) over 1 year ago

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.

Actions

Also available in: Atom PDF

Like0
Like0Like0Like0Like0Like0Like0Like0Like0