Porque as mensagens de erro geralmente vão para stderr
não stdout
.
Altere a invocação para:
taskkill /im "test.exe" /f >nul 2>&1
e tudo ficará melhor.
Isso funciona porque stdout
é o descritor de arquivo 1 e stderr
é o descritor de arquivo 2 por convenção. (0 é stdin
, aliás.) As 2>&1
cópias geram a saída do descritor 2 do novo valor 1, que foi redirecionado para o dispositivo nulo.
Esta sintaxe é (vagamente) emprestada de muitos shells Unix, mas você deve ter cuidado porque existem diferenças sutis entre a sintaxe do shell e CMD.EXE.
Atualização: eu sei que o OP entende a natureza especial do "arquivo" chamado para o qual NUL
estou escrevendo aqui, mas um comentarista não entendeu e, portanto, deixe-me divagar com mais detalhes sobre esse aspecto.
Voltando às primeiras versões do MSDOS, certos nomes de arquivos foram substituídos pelo kernel do sistema de arquivos e usados para se referir a dispositivos. A lista mais antigo desses nomes incluídos NUL
, PRN
, CON
, AUX
e COM1
através COM4
. NUL
é o dispositivo nulo. Ele sempre pode ser aberto para leitura ou gravação, qualquer valor pode ser escrito nele e as leituras sempre são bem-sucedidas, mas não retornam dados. Os outros incluem a porta paralela da impressora, o console e até quatro portas seriais. No MSDOS 5, havia vários outros nomes reservados, mas a convenção básica estava muito bem estabelecida.
Quando o Windows foi criado, ele começou como uma camada bastante fina de troca de aplicativos sobre o kernel do MSDOS e, portanto, tinha as mesmas restrições de nome de arquivo. Quando o Windows NT foi criado como um verdadeiro sistema operacional por si só, nomes como NUL
e COM1
foram amplamente considerados para funcionar para permitir sua eliminação. No entanto, a ideia de que novos dispositivos sempre receberiam nomes que bloqueariam o futuro usuário desses nomes para arquivos reais é obviamente irracional.
O Windows NT e todas as versões seguintes (2K, XP, 7 e agora 8) usam o namespace NT muito mais elaborado do código do kernel e para código de espaço do usuário cuidadosamente construído e altamente não portátil. Nesse espaço de nome, os drivers de dispositivo são visíveis por meio da \Device
pasta. Para oferecer suporte à compatibilidade com versões anteriores exigida, há um mecanismo especial usando a \DosDevices
pasta que implementa a lista de nomes de arquivos reservados em qualquer pasta do sistema de arquivos. O código do usuário pode navegar neste espaço de nome interno usando uma camada de API abaixo da API Win32 usual; uma boa ferramenta para explorar o namespace do kernel é WinObj do grupo SysInternals da Microsoft.
Para obter uma descrição completa das regras que envolvem os nomes legais de arquivos (e dispositivos) no Windows, esta página do MSDN será informativa e assustadora. As regras são muito mais complicadas do que deveriam ser e, na verdade, é impossível responder a algumas perguntas simples como "qual é o comprimento do nome de caminho totalmente qualificado legal mais longo?".