É seguro digitar outro comando no STDIN enquanto o comando anterior está gravando no STDOUT?

Question

Talvez isso tenha sido respondido anteriormente, gostaria de receber um link para outra resposta ...

Se eu executar um comando shell (em um bash shell) da seguinte forma:

make

Então, enquanto a saída de make estiver rolando a partir do comando STDOUT do comando make , se eu digitar make check e pressionar entre antes que o primeiro comando seja concluído, quando o comando make finalmente finalizar o próximo comando make check irá selecionar e executar.

A minha pergunta é simples:

1. Isso é perigoso fazer?
2. Há algum comportamento inesperado em potencial desse tipo de digitação rápida?
3. Por que isso funciona da maneira como funciona?

Answer 1

Funciona da maneira que faz porque o Unix é full-duplex. Como Ritchie disse em O Sistema de Compartilhamento de Tempo do UNIX: Uma Retrospectiva :

One thing that seems trivial, yet makes a surprising difference once one is used to it, is full-duplex terminal I/O together with read-ahead. Even though programs generally communicate with the user in terms of lines, rather than single characters, full-duplex terminal I/O means that the user can type at any time, even if the system is typing back, without fear of losing or garbling characters. With read-ahead, one need not wait for a response to every line. A good typist entering a document becomes incredibly frustrated at having to pause before starting each new line; for anyone who knows what he wants to say any slowness in response becomes psychologically magnified if the information must be entered bit-by-bit instead of at full speed.

[end quote]

Dito isto, existem alguns programas modernos que consomem ou descartam qualquer tipo de digitação; ssh e apt-get são dois exemplos. Se você digitar com antecedência enquanto estiver executando, poderá descobrir que a primeira parte de sua entrada desapareceu. Isso poderia ser um problema.

ssh remotehost do something that takes 20 seconds
mail bob
Dan has retired. Feel free to save any important files and then do
# ssh exits here, discarding the previous 2 lines
rm -fr *
.

    

Answer 2

O comportamento básico que você está vendo é que a entrada fica em um buffer em algum lugar até ser lida (bem, se você digitar o suficiente, eventualmente os buffers serão preenchidos e algo será perdido, isso seria um muito de digitação embora). A maioria das coisas executadas pelo make não são lidas no STDIN, portanto permanecem no buffer.

O perigo é que o comando errado lê sua entrada. Por exemplo, make chama algo que decide avisar você e, em seguida, pode ler o próximo comando como resposta. Como isso é perigoso depende do comando, claro. (Eles também podem liberar toda a entrada primeiro, apenas descartando sua entrada anterior.)

Um comando, comumente usado em Makefiles, pode fazer isso é o TeX. Se encontrar um erro (e não tiver recebido um sinalizador para nunca avisar o usuário), ele perguntará como você deseja continuar.

A melhor opção é provavelmente executar: make && make check .

    

Answer 3

1. Bem, obviamente, você não deve executar um segundo comando isso depende do primeiro comando ( make , no seu exemplo) ter sido concluído com sucesso. Por exemplo, make foo Digite > ./foo Enter pode causar um problema. Você pode tentar adquirir o hábito de digitar coisas como make && make check , onde o segundo comando será executado somente se o primeiro for bem-sucedido.
2. É teoricamente possível que o primeiro comando (processo (es)) poderia ler parte do segundo comando, ou então removê-lo do buffer de entrada do terminal. Se comeu os seis primeiros caracteres de make check , você acabaria executando o comando heck , o que provavelmente não existe no seu sistema (mas pode ser algo desagradável). Se o primeiro comando é algo benigno que você conhece e confia, Eu não vejo imediatamente nenhum problema.
3. Como e por que isso funciona? O sistema armazena a entrada do teclado. É um pouco como e-mail: você pode enviar uma pessoa cinco mensagens em um curto período de tempo, e eles vão se sentar em sua caixa de entrada, esperando que ele os leia. Da mesma forma, desde que o primeiro comando não esteja lendo no teclado, o (s) comando (s) que você digita irá se sentar e aguardar o shell dar a volta para lê-los. Existe um limite para o quanto de "digitação antecipada" pode ser armazenada em buffer, mas geralmente são várias centenas de caracteres (se não vários milhares).