[ruby-core:110792] [Ruby master Feature#19036] Provide a way to set path for File instances created with for_fd

[ruby-core:110792] [Ruby master Feature#19036] Provide a way to set path for File instances created with for_fd

[ko1 (Koichi Sasada)]

Issue #19036 has been updated by 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:

```ruby
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?


----------------------------------------
Feature #19036: Provide a way to set path for File instances created with for_fd
https://bugs.ruby-lang.org/issues/19036#change-100146

* Author: headius (Charles Nutter)
* Status: Open
* Priority: Normal
----------------------------------------
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:<slavename>" 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.



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

[ruby-core:111110] [Ruby master Feature#19036] Provide a way to set path for File instances created with for_fd

[ioquatix (Samuel Williams)]

Issue #19036 has been updated by 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.

----------------------------------------
Feature #19036: Provide a way to set path for File instances created with for_fd
https://bugs.ruby-lang.org/issues/19036#change-100382

* Author: headius (Charles Nutter)
* Status: Open
* Priority: Normal
----------------------------------------
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:<slavename>" 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.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:111119] [Ruby master Feature#19036] Provide a way to set path for File instances created with for_fd

[matz (Yukihiro Matsumoto)]

Issue #19036 has been updated by matz (Yukihiro Matsumoto).


LGTM.

Matz.


----------------------------------------
Feature #19036: Provide a way to set path for File instances created with for_fd
https://bugs.ruby-lang.org/issues/19036#change-100393

* Author: headius (Charles Nutter)
* Status: Open
* Priority: Normal
----------------------------------------
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:<slavename>" 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.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:111238] [Ruby master Feature#19036] Provide a way to set path for File instances created with for_fd

[ioquatix (Samuel Williams)]

Issue #19036 has been updated by 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:)`?


----------------------------------------
Feature #19036: Provide a way to set path for File instances created with for_fd
https://bugs.ruby-lang.org/issues/19036#change-100527

* Author: headius (Charles Nutter)
* Status: Closed
* Priority: Normal
----------------------------------------
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:<slavename>" 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.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:111242] [Ruby master Feature#19036] Provide a way to set path for File instances created with for_fd

[Eregon (Benoit Daloze)]

Issue #19036 has been updated by 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.

----------------------------------------
Feature #19036: Provide a way to set path for File instances created with for_fd
https://bugs.ruby-lang.org/issues/19036#change-100532

* Author: headius (Charles Nutter)
* Status: Closed
* Priority: Normal
----------------------------------------
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:<slavename>" 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.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/

[ruby-core:111244] [Ruby master Feature#19036] Provide a way to set path for File instances created with for_fd

[headius (Charles Nutter)]

Issue #19036 has been updated by 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.

----------------------------------------
Feature #19036: Provide a way to set path for File instances created with for_fd
https://bugs.ruby-lang.org/issues/19036#change-100535

* Author: headius (Charles Nutter)
* Status: Closed
* Priority: Normal
----------------------------------------
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:<slavename>" 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.



-- 
https://bugs.ruby-lang.org/
 ______________________________________________
 ruby-core mailing list -- ruby-core@ml.ruby-lang.org
 To unsubscribe send an email to ruby-core-leave@ml.ruby-lang.org
 ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/