> ok, i knew about this in the first place, i was just curious how
> 'entrenched' this feature is. Very entrenched, unfortunately. I suppose
> it's also in the Posix testsuite.
> i still havent seen any (technical) explanation why this is specified this
> way, IMHO it's a silly restriction that kills (well, seriously hinders) a
> fast+scalable file handling redesign.
> normal code really doesnt need to know what index the kernel gives.
There are programs out there that expect file descriptors to be
numbered like they are today. For instance you might see
sentences like the following in program documentation:
"qmail-popup expects descriptor 0 to read from the network
and descriptor 1 to write to the network. It reads a
username and password from descriptor 0 in POP's USER-PASS
style or APOP style. It invokes subprogram, with the same
descriptors 0 and 1; descriptor 2 writing to the network;
and descriptor 3 reading the username, a 0 byte, the pass-
word, another 0 byte, an APOP timestamp derived from host-
name, and a final 0 byte. qmail-popup then waits for sub-
program to finish. It prints an error message if subpro-
gram crashes or exits nonzero."
The traditional way piping between two processes has been
implemented also relies on the dup() system call to return the
first free slot in the descriptor table.
> the only real reason: scripts see the index 'directly', but as far as i've
> checked, 99% of this is restricted to 1> and 2>.
Making 0, 1 and 2 special cases would not be pretty, IMHO.
Johan Myreen
jem@iki.fi