Pode ajudar a entender o problema de uma perspectiva diferente. Digamos que você seja o programador encarregado de adicionar um agendador de tarefas ao Windows. Como você faria? Você tem vários problemas para enfrentar: Se a tarefa for executada como alguém que não seja o usuário conectado, você deve incomodar o usuário conectado com algum erro de pop-up? E se não houver usuário conectado no momento em que a tarefa for executada? E a diferença entre um programa GUI e um programa de console? As GUIs não possuem stdin, stdout e stderr; o conceito não tem sentido neles. E os programas internos ou externos ao COMMAND.COM/CMD.EXE? Ou outros mecanismos de script? E os caminhos com espaços no nome do comando? Ou nos parâmetros (opções / argumentos)? (Como você está tentando lidar agora ..)
Embora eu não tenha 100% de certeza sobre os detalhes internos ou técnicos completos neste caso, as respostas parecem ser .. As tarefas são executadas em uma sessão isolada e não interativa, que não pode interagir com o usuário conectado no momento (se houver) ); É executado esperando que não haja saída do console, uma vez que não é interativo, não pode simplesmente interromper qualquer usuário conectado para mostrar a saída de qualquer maneira (e se houver saída, stdin é o bitbucket / NULL, stdout e stderr são registrados no o recurso de registro do sistema); Os espaços são tratados ignorando o problema: o nome do comando é obtido EXATAMENTE como está e os parâmetros passados para o comando são especificados em outra caixa de entrada nas propriedades da Tarefa.
Todos os meios são que sua tarefa precisa ser executada como se fosse um daemon (no mundo Un * x). Tudo é estático e preciso. O nome do comando é o nome do comando real, sem nenhum parâmetro. Isso geralmente inclui a execução de intérpretes de comando / script, como o CMD.EXE! Os parâmetros, se houver, são especificados em outro lugar e devem ser conhecidos quando você configura a tarefa (ou seja, não é possível alterar os parâmetros "on-the-fly"). E assim por diante.
Portanto, se você deseja incluir parâmetros, é necessário usar a seção de parâmetros para especificar os parâmetros. O Agendador de tarefas nãotente analisar o nome do comando para dividi-lo em "command" e "args", como fazem os programas de linha de comando. Apenas o trata como um grande nome completo de comando. Da mesma forma, se você deseja parâmetros variáveis, como usar% 1 ..% n em arquivos BATCH, não pode fazê-lo no próprio Agendador de tarefas; Você terá que encontrar outro caminho. (Observe que você também não pode usar variáveis de ambiente, pois o ambiente passado para o programa depende do ambiente em que a tarefa foi iniciada, NÃO do ambiente "atual".) Você pode usar um arquivo temporário para salvar os parâmetros, mas desde que você deve especificar um nome de arquivo estático nas propriedades da tarefa, o que acontece quando você está em uma rede com 5000 usuários e quatro deles tentam executar a mesma tarefa ao mesmo tempo? Todos eles se atrapalham tentando gravar no mesmo arquivo temporário ao mesmo tempo, provavelmente também não é o que você queria. (Existem soluções para esse problema também, mas isso está muito além do escopo desta pergunta e resposta ..)
Resposta final: no caso simples - o caminho que você deseja passar como parâmetro é estático e não muda - é necessário especificar os parâmetros na propriedade Task apropriada (Arguments), em vez de na caixa Program / Script ou use um arquivo em lotes. Em um caso mais complexo - você precisará fazer a pergunta certa ou pesquisar como os daemons funcionam e como usar bloqueios / semáforos e outros para comunicação entre processos (IPC).
Boa sorte.
