Re:Towards userspaceification of POSIX – part I: signal hand...
by tbrownaw on Saturday August 03, 2024 @12:22AM
(#41144660)
> My reading of TFA was that it’s rare for it to be important that descriptors sharing a description thus also share a file position.
It reads like this was an assumption rather than an observation.
> And shell-like redirection use cases really are the only case I can think of where that’s important.
.xsession-errors , or really anything of that nature where a process tree shares an error log file on stderr.
Re:Towards userspaceification of POSIX – part I: signal hand...
by zzo38computer on Sunday August 04, 2024 @11:07PM
(#41157825)
I think "(almost-)everything-is-a-string (shell) language" is not the way to do it; the command shell can be designed in a better way. But, my intention of design of the command shell programming language of a operating system is that it would have object-capability powers, too (and will be called "Command, Automation, and Query Language").
My reading of TFA was that it’s rare for it to be important that descriptors sharing a description thus also share a file position. And shell-like redirection use cases really are the only case I can think of where that’s important.
> As for the seeking abstraction, it fits well with other buffered device driver information streams.
I don’t think I understand what you’re getting at here. My point was that having some objects (fds, whatever) support {fstat, read/write} only and others {fstat, pread/pwrite, mmap} only would get rid of the confusing user-visible notion of “file description”. Obviously I don’t expect this to happen, but it’s still nice to dream.