I don't blame you either; I've always preferred file handle to file descriptor, 
for that reason. As it is, the full list of flags is part of open(); fcntl only 
has FD_NONBLOCK because this is the only flag considered safe to modify while a 
file is open, however many times it's referenced. Changing from O_RDONLY to 
O_APPEND on the fly can be problematic to applications using pread(), for 
example, to access records from a database in parallel.
On Tuesday, January 14, 2020 Ronald F. Guilmette <r...@tristatelogic.com> wrote:
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


Reply via email to