De acordo com esta resposta , stdin , stdout e stderr estão todos inicialmente conectados para o mesmo local (o mesmo que /dev/tty ), e a convenção de ler a partir de stdin e gravar em stdout e stderr é apenas isso: uma convenção.
Nesse caso, por que separar os fluxos stdin e stdout , em vez de combiná-los em um único?
Um ponteiro FILE como stdin, stdout e stderr pode conter apenas um descritor de arquivo subjacente. Assim, se você tiver uma configuração de pipeline como:
ls | grep foo | less
Então stdin, stdout e stderr do grep têm fileno () s diferentes porque há dois pipe () s conectados. Portanto, deve haver diferentes FILEs também.
Ter um fluxo de entrada separado de um fluxo de saída torna mais fácil para um programa gravar sua saída ao mesmo tempo que está lendo sua entrada.
Isso torna mais fácil permitir que um programa grave sua saída em outro lugar, de onde veio sua entrada, usando redirecionamentos ou canais.
Além de ser apenas uma convenção , os três fluxos padrão de E / S também são padrão . Veja por exemplo a seção sobre fluxos de E / S padrão na parte de interfaces do sistema do padrão POSIX .
A justificativa para essa seção diz:
Although the ISO C standard guarantees that, at program start-up, stdin is open for reading and stdout and stderr are open for writing, this guarantee is contingent (as are all guarantees made by the ISO C and POSIX standards) on the program being executed in a conforming environment. Programs executed with file descriptor 0 not open for reading or with file descriptor 1 or 2 not open for writing are executed in a non-conforming environment. Application writers are warned [...] not to execute a standard utility or a conforming application with file descriptor 0 not open for reading or with file descriptor 1 or 2 not open for writing.
Tags stdout stdin io-redirection