In message <1676199645.11146898.1578981958...@mail.yahoo.com>, Shware Systems <shwares...@aol.com> wrote:
>Short answer, because both file descriptors reference the same file >description... OK. I see where I took a wrong turn now, however I must say that I cannot blame myself for having done so. The language being used for the base concepts here is exceptionally stilted. We have -descriptors- and then we have file -descriptions-. I get it now, but I cannot help but wish that the original drafters, way back when, had elected to be a bit less clever and bit more obvious in their coinage of the relevant terminology here. The term "file desctriptor" was grandfathered in from the ancient times of UNIX. So that was cast in stone and could not be reasonably changed. But I would have been a LOT happier if those standard drafters, back in the day, had elected to call what is apparently now called a "file description" something else... a "purple aardvark" or basically anything other that the thing they finally settled on, which is extraordinarily subject to misinterpretation, being as it is, so close to the term "file descriptor". Moving ahead, now that my misreading has been corrected, I'd like to just throw out a trial balloon and note that it would be pragmatically useful to provide some attributes that are currently associated only with "file descriptions" also for file descriptors. O_NONBLOCK is the one that is most immediately apparent to me, but I can readily imagine usefulness also for permitting things like O_APPEND and even O_RDONLY and O_WRONLY to be applied selectively to individual file descriptors, rather than to (shared) file descriptions. I will happily elaborate on a real-world scenario in which this would have been most useful to have, if anyone is interested, and also the ugly ccode contortions that had to be applied in order to work-around this particular non- feature, which I am now aware is 100% standard conformant. Regards, rfg