Por que os descritores de arquivo são compartilhados entre processos bifurcados?

Considere um trecho de shell

{ somecmd; othercommand *.txt; } > outputfile

O shell abre outputfileuma vez, ao iniciar o redirecionamento, e depois passa o identificador do arquivo para o somecmde othercmd, processa- forko. Dado o agrupamento, o usuário pode não estar errado ao esperar que a saída de ambos os comandos termine em outputfile, da mesma forma que terminariam na tela. (Isso seria o mesmo se o { }grupo fosse um script de shell.)

Se a posição do arquivo fosse independente para todos os processos, a saída de othercommandsobrepujaria a saída de somecmd. Se um forkredefinisse a posição no identificador de arquivo, o shell não teria como passar othercommandum identificador que apontasse para o final de outputfile(como era depois de somecmd). Teríamos que usar um canal para coletar a saída de ambos os comandos (eles são independentes de posição de qualquer maneira) e ter outro programa concatenando a saída dos dois:

{ somecmd; othercommand *.txt } | cat > outputfile

POSIX explica o raciocínio assim :

Existem duas razões pelas quais os programadores POSIX chamam fork() . Um motivo é criar uma nova thread de controle dentro do mesmo programa (o que originalmente só era possível no POSIX criando um novo processo); a outra é criar um novo processo executando um programa diferente. No último caso, a chamada para fork() é logo seguida por uma chamada para uma das funções exec .

Quando fork()é usado como um “threading do pobre”, faz sentido copiar os descritores do arquivo. Esse caso de uso deve continuar a ser suportado, portanto, esse recurso permanecerá...