On 12 May 2015 at 18:10, Daniel Bastos <[email protected]> wrote:
> could never work because it requires opening /fd/1 for reading, which
> is not possible. Is this conclusion incorrect?
>
It's not right. I'll try again.
/fd/1 gives a name to file descriptor 1.
When opened, you get a new file descriptor (not 1) that refers to the same
open file instance as file descriptor 1.
If file descriptor 1 was opened with a given mode (M, say), then /fd/1 can
only
be opened with a mode compatible with mode M.
Opening for read (OREAD) works with existing mode M being OREAD or ORDWR;
opening for write (OWRITE) works with existing mode being OWRITE or ORDWR;
opening for read-write ( ORDWR) is compatible only with ORDWR.
If opening with /fd/1 returns a permission error (inappropriate use),
that's because
the mode used to open it wasn't compatible with the mode of the open or
create
that put an open file in file descriptor slot 1.
The file permission shown for /fd/N tells you the open mode of the
underlying file descriptor:
if only w, then only OWRITE, if only r, then OREAD, if rw, then ORDWR.
Finally, you can indeed open /fd/1 for reading if file descriptor 1 was
itself opened for read:
h% rc <>[1]/dev/cons # open /dev/cons read-write as file
descriptor 1
h% ls -l /fd/1
--rw------- d 0 bootes bootes 0 Jul 2 2014 /fd/1 # it says it's
read-write
h% echo hi >/fd/1 # i can write
hi
h% read -n 1 /fd/1 # i can read
hi yourself
hi yourself
Something I wrote earlier came out as the opposite of what I'd intended:
> (the new open can add OCEXEC, which will apply to both)
I don't know why I said that. I meant to write that it will "apply only to
the newly opened file".
