[#111472] [Ruby master Bug#19274] Error installing ruby 3.2.0 on RH 8 — "aalllop (Alberto Allegue) via ruby-core" <ruby-core@...>
Issue #19274 has been reported by aalllop (Alberto Allegue).
5 messages
2022/12/28
[#111508] Data support for versions before 3.2.0 — Eustáquio Rangel via ruby-core <ruby-core@...>
I was wondering that every piece of code (gems, etc) that use the new Data =
3 messages
2022/12/29
[ruby-core:111244] [Ruby master Feature#19036] Provide a way to set path for File instances created with for_fd
From:
"headius (Charles Nutter)" <noreply@...>
Date:
2022-12-09 08:50:36 UTC
List:
ruby-core #111244
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 -- [email protected]
To unsubscribe send an email to [email protected]
ruby-core info -- https://ml.ruby-lang.org/mailman3/postorius/lists/ruby-core.ml.ruby-lang.org/