Podría ayudar a entender el problema desde una perspectiva diferente.. Digamos que eres el programador al que se le ha encargado añadir un programador de tareas a Windows. ¿Cómo lo harías? Tienes varios problemas a los que enfrentarte: Si la tarea se ejecuta como alguien que no es el usuario que ha iniciado la sesión, ¿debería molestar al usuario que ha iniciado la sesión con ventanas emergentes de error? ¿Qué pasa si no hay ningún usuario conectado en el momento en que se ejecuta la tarea? ¿Qué pasa con la diferencia entre un programa de GUI y un programa de consola? Las GUI no tienen stdin, stdout y stderr; el concepto no tiene sentido en ellas. ¿Qué pasa con los programas internos o externos a COMMAND.COM/CMD.EXE? ¿O de otros motores de scripting? ¿Qué pasa con las rutas con espacios en el nombre del comando? ¿O en los parámetros (opciones/argumentos)? (Como estás tratando de hacer ahora..)
Aunque no estoy 100% seguro de las interioridades o detalles técnicos completos en este caso, las respuestas parecen ser.. Las tareas se ejecutan en una sesión aislada, no interactiva, que no puede interactuar con el usuario actualmente conectado (si hay alguno); Se ejecuta esperando que no haya salida de consola, ya que es no interactiva, no puede interrumpir a cualquier usuario conectado para mostrar la salida, de todos modos (y si hay salida, stdin es el bitbucket/NULL, stdout y stderr se registran en la instalación de registro del sistema); Los espacios se manejan omitiendo la cuestión: el nombre del comando se toma EXACTAMENTE como es, y los parámetros que se pasan al comando se especifican en otro cuadro de entrada en las propiedades de la Tarea.
Lo que todo esto significa es que su tarea debe ejecutarse como si fuera un demonio (en el mundo Un*x). Todo es estático y preciso. El nombre del comando es el nombre real del comando, sin ningún parámetro. ¡Esto incluye a menudo la ejecución de intérpretes de comandos/script, como CMD.EXE! Los parámetros, si los hay, se especifican en otro lugar, y deben conocerse cuando se configura la tarea (es decir, no se pueden cambiar los parámetros “sobre la marcha”). Y así sucesivamente.
Por lo tanto, si quiere incluir parámetros, tiene que utilizar la sección de parámetros para especificarlos. El Programador de Tareas no trata de analizar el nombre del comando para dividirlo en “comando” y “argumentos” como hacen los programas de línea de comandos. Simplemente lo trata como un nombre de comando grande y completo. Asimismo, si desea parámetros variables, como el uso de %1 .. %n en los archivos BATCH, no puede hacerlo desde el propio Programador de Tareas; tendrá que encontrar otra forma. (Tenga en cuenta que tampoco puede utilizar variables de entorno, ya que el entorno que se pasa al programa depende del entorno con el que se inicia la tarea, NO del entorno “actual”). Podría utilizar un archivo temporal para guardar los parámetros, pero como debe especificar un nombre de archivo estático en las propiedades de la tarea, ¿qué sucede cuando está en una red con 5000 usuarios y cuatro de ellos intentan ejecutar la misma tarea al mismo tiempo? Todos ellos se golpearán entre sí tratando de escribir en el mismo archivo temporal al mismo tiempo, probablemente no es lo que usted quería, tampoco. (También hay soluciones a este problema, pero eso se sale del ámbito de esta pregunta y respuesta…)
Así que respuesta final: En el caso simple – la ruta que quiere pasar como parámetro es estática y no cambia – tiene que especificar los parámetros en la propiedad apropiada de la Tarea (Argumentos) en lugar de en la caja de Programa/Script, o usar un archivo por lotes. En un caso más complejo – tendrás que hacer la pregunta adecuada o investigar cómo funcionan los demonios y cómo usar los bloqueos/semáforos y demás para la comunicación entre procesos (IPC).
Buena suerte.