On Wednesday, October 29, 2025, at 4:09 PM, Dan Cross wrote: > pipefile(1) does something very close to this already. Perhaps you can use it directly? If not, perhaps its implementation may be useful as a source of ideas. Thanks for that! I'll have a closer look. The bugs section mentions that it ought to be rewritten as a user file server, so I guess it's a bit of a compromise.
On Wednesday, October 29, 2025, at 4:10 PM, Jacob Moody wrote: > Can you give us some more context about why you're attempting to use an > already open file descriptor as /dev/cons? I'm porting my window system to plan 9. One of the ways its different from rio is that the programs that run in the separate windows share a namespace by default. That's not required, but rforking the namespace is not required by the window system either. It also doesn't have a /dev/cons as such, but some text-oriented programs on Plan 9 (e.g. p(1)) will depend on finding that in the namespace. So I want that to be possible for interoperability. On Wednesday, October 29, 2025, at 4:10 PM, Jacob Moody wrote: > Essentially, instead of working backwards from a low context situation (just > the fd), have the parent or caller do a bit more work to setup with the environment where they do have the context. This seems like the way to go - but I also want to avoid rforking the namespace for all text windows just for the programs that need /dev/cons. I think sometimes it's nice for shells in windows to share a namespace... perhaps I'm just not thinking plan9y enough. My text window program normally puts a distinct name in the shared namespace for each instance e.g. /dev/tty1 - something I've used relatively rarely in practice, and I wasn't committing to recreate on plan 9. But perhaps I should. I can use named pipes on the Plan 9 version as you describe and, after an rfork, bind /dev/cons to whichever is the contextual one. I need to figure out how to find which named pipe should be bound to /dev/cons. I have an idea involving naming the named pipes with their qid.path, e.g. "/n/pipe3f941". I can recover the qid.path number in an fstat of one of the open fds, so I could then generate the name of the file to bind from that (is that a bit hokey??) Alternatively I could "rfork e" and put the pipe path in an environment variable for later use. That seems nicer, but I'm not really sure I want my window system to "rfork e" for me either... Hmm. Not sure what's best at this point. Many thanks for the advices! I think I have some possible ways forward now, but it's far from finished. ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4a173cfd35edc215-M9d1461d61efeb3c813cddbaf Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
