Hacker News Reader

Comment by vacuity | Hacker News Reader

I think standardizing a file descriptor interface would be ideal. It's ridiculous that the file descriptors are exposed and densely packed. I wonder if a protocol could be made that demultiplexes for stderr and the new file descriptor could be made.

View on HN

I do not understand very well what you mean.

I'd like to make another standard file descriptor to manage the control plane, like stdin/stdout/stderr, but figuring out which file descriptor it should be is a bit complicated. I'm wondering if the OS could backwards-compatibly integrate it with stderr in the standard file descriptor at index 2.

Historically some systems did have more than three standard file descriptors - e.g. for MS-DOS C compilers, a de facto standard was stdprn was your printer and stdaux was a serial port - this was because while Unix by default starts each process with 3 inherited handles, MS-DOS has 5 (CP/M influence). NT-based Windows abandoned this

But trying to add a fourth now, would likely break too many things; some software will assume any fd > 2 is free for it to clobber.

The IBM mainframe operating system z/OS (formerly MVS), classically instead of numbers for inherited descriptors, the API uses names (DDNAMEs)-that would have made adding a new one a lot easier. But decades too late for that in Unix land, and eventually MVS added the Unix way too for Unix compatibility-the classic API still uses DDNAMEs, but many apps now use the file descriptor-based z/OS Unix API instead

OK, but I don't know how you would integrate it with an existing file descriptor. (It is why I suggested using a environment variable to manage this.)

You can open another file descriptor at any time and some programs allow you to specify a file descriptor instead of the filename.

Reply on news.ycombinator.com