Pode ajudar a compreender o problema a partir de uma perspectiva diferente. Digamos que é o programador que foi encarregado de adicionar um programador de tarefas ao Windows. Como o faria? Tem vários problemas com que se defrontar: Se a tarefa for executada como outra pessoa que não o utilizador ligado, deverá irritar o utilizador ligado com algum erro de popups? E se não houver nenhum utilizador logado no momento em que a tarefa é executada? E quanto à diferença entre um programa GUI e um programa de consola? As GUI não têm stdin, stdout, e stderr; o conceito não tem sentido nelas. E os programas internos ou externos ao COMMAND.COM/CMD.EXE? Ou outros motores de scripting? E quanto aos caminhos com espaços no nome do comando? Ou nos parâmetros (opções/argumentos)? (Como está a tentar lidar com agora…)
Embora não esteja 100% certo sobre os internos ou detalhes técnicos completos neste caso, as respostas parecem ser… As tarefas são executadas numa sessão isolada, não interactiva, que não pode interagir com o utilizador actualmente registado (se houver); É executado esperando que não haja saída da consola, uma vez que é não interactiva, não pode simplesmente interromper qualquer utilizador registado para mostrar a saída, de qualquer forma (e se houver saída, stdin é o bitbucket/NULL, stdout e stderr são registados na instalação de registo do sistema); Os espaços são tratados contornando o problema: o nome do comando é tomado EXACTLY tal como está, e os parâmetros são passados para o comando são especificados noutra caixa de entrada nas propriedades da Tarefa.
O que tudo significa é que a sua tarefa tem de ser executada como se fosse um daemon (no mundo Un*x). Tudo é estático e preciso. O nome do comando é o verdadeiro nome do comando, sem quaisquer parâmetros. Isto inclui muitas vezes a execução de intérpretes de comando/script, tais como CMD.EXE! Os parâmetros, se existirem, são especificados noutro local, e devem ser conhecidos quando se configura a tarefa (ou seja, não se pode alterar os parâmetros “on-the-fly”). E assim por diante.
Portanto, se quiser incluir parâmetros, tem de utilizar a secção de parâmetros para especificar os parâmetros. O Agendador de Tarefas não tenta analisar o nome do comando para o dividir em “comando” e “args”, como fazem os programas de linha de comando. Apenas o trata como um nome de comando grande e completo. Da mesma forma, se quiser parâmetros variáveis, como a utilização de %1 … %n em ficheiros BATCH, não o pode fazer a partir do próprio Agendador de Tarefas; terá de encontrar outra forma. (Note que também não pode utilizar variáveis de ambiente, uma vez que o ambiente passado para o programa depende do ambiente com que a tarefa é iniciada, NÃO do ambiente “actual”). Poderá utilizar um ficheiro temporário para guardar os parâmetros, mas como deve especificar um nome de ficheiro estático nas propriedades da Tarefa, o que acontece quando se está numa rede com 5000 utilizadores e quatro deles tentam executar a mesma tarefa ao mesmo tempo? Todos eles vão tentar escrever no mesmo ficheiro temporário ao mesmo tempo, provavelmente também não o que você queria. (Também há soluções para este problema, mas isso vai demasiado longe fora do âmbito desta pergunta e resposta…)
Portanto, resposta final: No caso simples – o caminho que pretende passar como parâmetro é estático e não muda – ou tem de especificar os parâmetros na propriedade Tarefa apropriada (Argumentos) em vez de na caixa Programa/Roteiro, ou utilizar um ficheiro de lote. Num caso mais complexo – terá de fazer a pergunta certa ou pesquisar como funcionam os demónios e como utilizar o bloqueio/semáforos e tais para a comunicação inter-processo (IPC).
Boa sorte.