O comando mais no Windows afeta somente a saída ou a execução de comandos também?

Question

Estou executando uma compilação de software no Visual Studio 2005 no Win XP através da linha de comando (devenv.exe / rebuild). Eu canalizei ainda mais e, em seguida, percebi que eu não queria ter que sentar para que eu parasse mais com Q. Agora eu não vejo nada na janela do CMD. O comando é executado normalmente, e mais apenas buffers e exibe STDOUT, e continuará a ser executado apesar de mais ser encerrado, ou esta build agora nunca será concluída?

    

Answer 1

Pergunta interessante!

O processo que você canalizou para o MORE continuará a ser executado até sua conclusão natural ou até que você o mate. Aqui está um teste para mostrá-lo:

Abra 2 janelas do cmd.

No prompt, uma corrida: ping -n 120 127.0.0.1 | mais

No prompt dois, execute: lista de tarefas | findstr / I ping

O ping será executado por aproximadamente 120 segundos, mas com uma janela cmd padrão alcançará uma página cheia em menos tempo do que isso (ajuste o comando ping de acordo).

Você pode mostrar no prompt dois que o PING continua executando se você quer ou não MAIS com "Q". É apenas matando o comando PING completamente com ctrl + C, ou esperando os 50 segundos completos, que o ping está parado.

    

Answer 2

Sim, more buffers e o processo continua a ser executado mesmo que você não role a saída.

Se você sair do more early, os erros nonexistent pipe do aparecerão em algumas circunstâncias. Isso parece não ter impacto na execução e é provavelmente devido ao método de teste usado.

Podemos testar com um arquivo em lote simples:

@echo off
for /l %%a in (1,1,100) do echo %%a
msg * done

Ao canalizar isso para more , é evidente que o processo continua a ser executado independentemente de se more está rolado ou não: vemos a mensagem done sem avançar more .

No entanto, se aumentarmos o tempo de execução assim e sairmos do more com q mid-command:

@echo off
for /l %%a in (1,1,10000) do echo %%a
msg * done

Recebemos muitas mensagens de erro:

The process tried to write to a nonexistent pipe.

A caixa de mensagem ainda aparece. O novo teste com um programa C # ou C simples não replica esse comportamento. Meu palpite é que, se o fluxo já estiver aberto, ele continuará normalmente (sem saída) - mas o comando echo usado nos testes acima realmente tenta abrir o fluxo todo o tempo e, assim que o destino do canal for fechado, não é mais possível.