Início / unix / Perguntas / 450713
Accepted
Fixee
Asked: 2018-06-20 11:46:00 +0800 CST

Pipes nomeados, descritores de arquivos e EOF

  • 772

Duas janelas, mesmo usuário, com prompts do bash. Na janela-1 digite:

$ mkfifo f; exec <f

Portanto, o bash agora está tentando ler do descritor de arquivo 0, que é mapeado para pipe nomeado f. Na janela-2 digite:

$ echo ls > f

Agora window-1 imprime um ls e então o shell morre. Por quê?

Próxima experiência: abra a janela-1 novamente com exec <f. Na janela-2 digite:

$ exec 3>f
$ echo ls >&3

Após a primeira linha acima, a janela-1 acorda e imprime um prompt. Por quê? Após a segunda linha acima, a janela-1 imprime a lssaída e o shell permanece ativo. Por quê? Na verdade, agora na janela-2, echo ls > fnão fecha o shell da janela-1.

A resposta deve ter a ver com a existência do descritor de arquivo 3 da janela-2 referenciando o pipe nomeado?!

fifo file-descriptors

3 respostas

  1. Best Answer

    Tem a ver com o fechamento do descritor de arquivo.

    Em seu primeiro exemplo, echograva em seu fluxo de saída padrão que o shell abre para conectá-lo fe, quando termina, seu descritor é fechado (pelo shell). Na extremidade receptora, o shell, que lê a entrada de seu fluxo de entrada padrão (conectado a f) lê ls, executa lse termina devido à condição de fim de arquivo em sua entrada padrão.

    A condição de fim de arquivo ocorre porque todos os gravadores no pipe nomeado (apenas um neste exemplo) fecharam sua extremidade do pipe.

    Em seu segundo exemplo, exec 3>fabre o descritor de arquivo 3 para gravar em f, depois echograva lsnele. É o shell que agora tem o descritor de arquivo aberto, não o echocomando. O descritor permanece aberto até que você o faça exec 3>&-. Na extremidade receptora, o shell, que lê a entrada de seu fluxo de entrada padrão (conectado a f) lê ls, executa lse aguarda mais entradas (já que o fluxo ainda está aberto).

    O fluxo permanece aberto porque todos os escritores para ele (o shell, via exec 3>fe echo) não fecharam sua extremidade do canal ( exec 3>fainda está em vigor).

    Eu escrevi echoacima como se fosse um comando externo. É mais provável que esteja embutido no shell. O efeito é o mesmo, no entanto.

    • 13

  2. Não há muito para isso: quando não há escritores no pipe, ele parece fechado para os leitores, ou seja, retorna EOF quando lido e bloqueia quando aberto.

    Na página de manual do Linux ( pipe(7), mas veja também fifo(7)):

    Se todos os descritores de arquivo referentes ao final de gravação de um pipe tiverem sido fechados, uma tentativa de read(2)partir do pipe verá end-of-file ( read(2)retornará 0).

    Fechar o final de gravação é o que acontece implicitamente no final do echo ls >f, e como você diz, no outro caso, o descritor de arquivo é mantido aberto.

    • 7

  3. Depois de ler as duas respostas de @Kusalananda e @ikkachu, acho que entendi. Na janela-1, o shell está esperando por algo para abrir a extremidade de gravação do pipe e depois fechá-lo. Uma vez que o final de gravação é aberto, o shell na janela-1 imprime um prompt. Uma vez que o final da gravação é fechado, o shell recebe EOF e morre.

    No lado da janela 2, temos as duas situações descritas na minha pergunta: na primeira situação com echo ls > f, não há descritor de arquivo 3, então temos echospawning, e é stdinassim stdout:

    0 --> tty
1 --> f

    Em seguida, echotermina e o shell fecha ambos os descritores. Como o descritor de arquivo 1 está fechado e referências f, o final de gravação de fé fechado e isso faz com que um EOF seja janela-1.

    Na segunda situação, rodamos exec 3>fem nosso shell, fazendo com que o shell tome este ambiente:

    bash:
0 --> tty
1 --> tty
2 --> tty
3 --> f

    Agora executamos echo ls >& 3e o shell aloca descritores de arquivo da echoseguinte forma:

    echo:
0 --> tty
1 --> f     # because 3 points to f
2 --> tty

    Em seguida, o shell fecha os três descritores acima, incluindo f, mas fainda tem uma referência a ele do próprio shell. Esta é a diferença importante. Fechar o descritor 3 com exec 3>&-fecharia a última referência aberta e causaria um EOF na janela-1, como observou @Kusalananda.

    • 3

relate perguntas