5 ms·

Not sure if it's specifically unix design, but it's something I attribute to Unix. In my experience something I think was short-sighted was for stdin and stdout

Not sure if it's specifically unix design, but it's something I attribute to Unix. In my experience something I think was short-sighted was for stdin and stdout to be two separate file descriptors, and for everyone to assume they're pipes, and to assume that pipes are unidirectional. I want stdio to be fd0 and it to be both readable and writeable. I want it to be socket-like. Read from "stdin", and you read from fd0 and it's a socket. Write to "stdout", and you write to the same fd0. It would simplify child process handling code since you can use one call to `socketpair()` for stdio. Stderr could be implemented on top of the out-of-band stream, and for program-to-program communications on Linux with a domain socket, you can pass file descriptors and discover the PID of your peer.

jstanley 8y ago
And how does that work in a shell pipeline? Stdin comes from one process and stdout goes to another. This is easy if stdin and stdout can be separate places.
- gizmo686 8y ago
  There is no real reason why the read call and write call on a filedescriptor need to go to the same place. To make this work well, I think you would need the concept of a pipeline at the file level. Eg, if process A has a pipeline file pipeA, and process B has a pipeline file pipeB, you would need some form of linkPipe(pipeA,pipeB) syscall that causes in in buffer of pipeB to be the same as the outbuffer of pipeA. Granted, this breaks the general model of a file representing a single block of bytes that both reads and writes operate on, but that model is already gone in UNIX (eg, the in and out buffer for sockets are seperate). I'm not convinced this is actually a good idea, but seems doable.
- inetknght 8y ago
  I think it's rather short-sighted to think of a shell pipeline as unidirectional. Imagine if you want to be able to provide random seeking capability to your input source but the seek destinations determined by the output consumer? That's rather difficult to do with a unidirectional pipeline.
jimktrains2 8y ago
Wouldn't that break the concept of pipes though, that is the concept that you read from the previous program/keyboard/file and write to the next program/screen/file? It's pretty easy to use a Unix socket for what you were describing.
- inetknght 8y ago
  Why would it break the concept of pipes?
  - jimktrains2 8y ago
    When you write to stdout, you're often not writing back to where stdin came from. Pipes use this to chain programs, read from one, write to another.
    - inetknght 8y ago
      I don't think it breaks the concept of pipes. I think it breaks the concept of _pipelines_. When I think of pipes, I think of an operating system concept of synchronized DMA between unique address spaces. When I think of pipelines, I think of what you're talking about, a sequence of programs handling data between them. I don't see why a pipeline should be unidirectional though.
      - jimktrains2 8y ago
        > I don't think it breaks the concept of pipes. I think it breaks the concept of _pipelines_. Fair enough. > I don't see why a pipeline should be unidirectional though. Piplines usually only carry material from one side to the other :) (yes, pneumatic ones are different :)) It's part "just because that made sense at the time" and partially because it does make sense: Give data to A, take the output and process it, give that to C, &c. However, a bidirectional, or even multiple, pipe would have some advantages, such as signaling.
chubot 8y ago
Hm, DJB actually argues the opposite, that sockets should have 2 file descriptors :) https://cr.yp.to/tcpip/twofd.html https://cr.yp.to/tcpip/twofd.html

jstanley 8y ago

And how does that work in a shell pipeline? Stdin comes from one process and stdout goes to another. This is easy if stdin and stdout can be separate places.

gizmo686 8y ago
There is no real reason why the read call and write call on a filedescriptor need to go to the same place. To make this work well, I think you would need the concept of a pipeline at the file level. Eg, if process A has a pipeline file pipeA, and process B has a pipeline file pipeB, you would need some form of linkPipe(pipeA,pipeB) syscall that causes in in buffer of pipeB to be the same as the outbuffer of pipeA. Granted, this breaks the general model of a file representing a single block of bytes that both reads and writes operate on, but that model is already gone in UNIX (eg, the in and out buffer for sockets are seperate). I'm not convinced this is actually a good idea, but seems doable.
inetknght 8y ago
I think it's rather short-sighted to think of a shell pipeline as unidirectional. Imagine if you want to be able to provide random seeking capability to your input source but the seek destinations determined by the output consumer? That's rather difficult to do with a unidirectional pipeline.

jimktrains2 8y ago

Wouldn't that break the concept of pipes though, that is the concept that you read from the previous program/keyboard/file and write to the next program/screen/file? It's pretty easy to use a Unix socket for what you were describing.

inetknght 8y ago
Why would it break the concept of pipes?
- jimktrains2 8y ago
  When you write to stdout, you're often not writing back to where stdin came from. Pipes use this to chain programs, read from one, write to another.
  - inetknght 8y ago
    I don't think it breaks the concept of pipes. I think it breaks the concept of _pipelines_. When I think of pipes, I think of an operating system concept of synchronized DMA between unique address spaces. When I think of pipelines, I think of what you're talking about, a sequence of programs handling data between them. I don't see why a pipeline should be unidirectional though.
    - jimktrains2 8y ago
      > I don't think it breaks the concept of pipes. I think it breaks the concept of _pipelines_. Fair enough. > I don't see why a pipeline should be unidirectional though. Piplines usually only carry material from one side to the other :) (yes, pneumatic ones are different :)) It's part "just because that made sense at the time" and partially because it does make sense: Give data to A, take the output and process it, give that to C, &c. However, a bidirectional, or even multiple, pipe would have some advantages, such as signaling.

chubot 8y ago

Hm, DJB actually argues the opposite, that sockets should have 2 file descriptors :) https://cr.yp.to/tcpip/twofd.html https://cr.yp.to/tcpip/twofd.html