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 logado, você deve irritar o usuário logado com algum erro de pop-up? E se não houver usuário logado no momento em que a tarefa é executada? E quanto à diferença entre um programa GUI e um programa de console? GUI não tem stdin, stdout e stderr; o conceito não tem sentido neles. E quanto aos programas internos ou externos ao COMMAND.COM/CMD.EXE? Ou outros mecanismos de script? E quanto aos 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 esteja 100% certo sobre os internos ou detalhes técnicos completos neste caso, as respostas parecem ser ... As tarefas são executadas em uma sessão isolada, não interativa, que não pode interagir com o usuário atualmente conectado (caso existam); É executado esperando que não haja saída do console, já que não é interativo, não pode simplesmente interromper qualquer usuário logado para mostrar a saída, de qualquer forma (e se houver saída, stdin é o bitbucket / NULL, stdout e stderr são logados para a facilidade de registro do sistema); Espaços são manipulados contornando o problema: o nome do comando é EXATAMENTE como está, e os parâmetros são passados para o comando são especificados em outra caixa de entrada nas propriedades da Tarefa.
O que significa que sua tarefa deve ser executada como se fosse um daemon (no Un * x world). Tudo é estático e preciso. O nome do comando é o nome real do comando, sem nenhum parâmetro. Isso geralmente inclui interpretadores de comandos / scripts, 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ê quiser incluir parâmetros, terá que usar a seção de parâmetros para especificar os parâmetros. O Agendador de Tarefas não tenta analisar o nome do comando para dividi-lo em "comando" e "args", como os programas de linha de comando. Apenas o trata como um nome de comando grande e completo. Da mesma forma, se você quiser parâmetros variáveis, como usar% 1 ..% n em arquivos BATCH, não poderá fazer isso 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 transmitido ao 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 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? Eles vão todos se atrapalhar tentando escrever no mesmo arquivo temporário ao mesmo tempo, provavelmente não o que você queria. (Existem soluções para esse problema também, mas isso está indo longe demais do escopo desta pergunta e resposta ..)
Assim, a resposta final: No caso simples - o caminho que você deseja passar como um parâmetro é estático e não muda - você precisa especificar os parâmetros na propriedade Task apropriada (Argumentos) e não no Programa. / Caixa de 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 travamentos / semáforos e outros para comunicação entre processos (IPC).
Boa sorte.
