Il pourrait être utile de comprendre le problème sous un autre angle.. Disons que vous êtes le programmeur qui a été chargé d'ajouter un planificateur de tâches à Windows. Comment le feriez-vous ? Vous devez faire face à plusieurs problèmes : Si la tâche est exécutée par une personne autre que l'utilisateur connecté, devez-vous déranger l'utilisateur connecté avec des popups d'erreur ? Que faire si aucun utilisateur n'est connecté au moment où la tâche est exécutée ? Quelle est la différence entre un programme d'interface graphique et un programme de console ? Les interfaces graphiques n'ont pas de stdin, stdout et stderr ; le concept n'a aucun sens dans ces interfaces. Qu'en est-il des programmes internes ou externes à COMMAND.COM/CMD.EXE ? Ou d'autres moteurs de script ? Qu'en est-il des chemins avec des espaces dans le nom de la commande ? Ou dans les paramètres (options/arguments) ? (Comme vous essayez de le faire maintenant..)
Bien que je ne sois pas sûr à 100% des détails techniques ou internes dans ce cas, les réponses semblent être.. Les tâches sont exécutées dans une session isolée, non interactive, qui ne peut pas interagir avec l'utilisateur actuellement connecté (s'il y en a un) ; elle est exécutée en s'attendant à ce qu'il n'y ait pas de sortie de console, puisqu'elle est non interactive, elle ne peut pas simplement interrompre un utilisateur connecté pour montrer la sortie, de toute façon (et s'il y a une sortie, stdin est le bitbucket/NULL, stdout et stderr sont enregistrés dans le système de journalisation) ; les espaces sont gérés en contournant le problème : le nom de la commande est pris EXACTEMENT tel quel, et les paramètres passés à la commande sont spécifiés dans une autre zone de saisie dans les propriétés de la tâche.
Ce qui signifie que votre tâche doit être exécutée comme si elle était un démon (dans le monde Un*x). Tout est statique et précis. Le nom de la commande est le nom réel de la commande, sans aucun paramètre. Cela inclut souvent l'exécution d'interprètes de commandes/scripts, tels que CMD.EXE ! Les paramètres, s'ils existent, sont spécifiés ailleurs et doivent être connus lors de la configuration de la tâche (c'est-à-dire que vous ne pouvez pas modifier les paramètres “à la volée”). Et ainsi de suite.
Donc, si vous voulez inclure des paramètres, vous devez utiliser la section des paramètres pour les spécifier. Le planificateur de tâches n'essaie pas d'analyser le nom de la commande pour la diviser en “command” et “args” comme le font les programmes en ligne de commande. Il le traite simplement comme un grand nom de commande complet. De même, si vous voulez des paramètres variables, comme l'utilisation de %1 … %n dans les fichiers BATCH, vous ne pouvez pas le faire à partir du planificateur de tâches lui-même ; vous devrez trouver un autre moyen. (Notez que vous ne pouvez pas non plus utiliser de variables d'environnement, puisque l'environnement transmis au programme dépend de l'environnement avec lequel la tâche est lancée, et NON de l'environnement “actuel”). Vous pourriez utiliser un fichier temporaire pour enregistrer les paramètres, mais puisque vous devez spécifier un nom de fichier statique dans les propriétés de la tâche, que se passe-t-il lorsque vous êtes sur un réseau de 5000 utilisateurs et que quatre d'entre eux essaient d'exécuter la même tâche en même temps ? Ils vont tous s'affronter en essayant d'écrire dans le même fichier temporaire en même temps, ce qui n'est probablement pas non plus ce que vous vouliez. (Il y a aussi des solutions à ce problème, mais cela dépasse trop le cadre de cette question et de cette réponse).
Donc, réponse finale : Dans le cas simple – le chemin que vous voulez passer en paramètre est statique et ne change pas – vous devez soit spécifier les paramètres dans la propriété appropriée de la tâche (Arguments) plutôt que dans la boîte Program/Script, soit utiliser un fichier batch. Dans un cas plus complexe – vous devrez poser la bonne question ou faire des recherches sur le fonctionnement des démons et sur l'utilisation des verrouillages/sémaphores et autres pour la communication inter-processus (IPC).
Bonne chance.