Podría ayudar a comprender el problema desde una perspectiva diferente. Digamos que usted es el programador a quien se le ha encargado agregar un programador de tareas a Windows. ¿Como lo harias? Tiene varios problemas con los que lidiar: si la tarea se ejecuta como alguien que no sea el usuario conectado, ¿debería molestar al usuario conectado con alguna ventana emergente de error? ¿Qué sucede si no hay un usuario conectado en el momento en que se ejecuta la tarea? ¿Qué pasa con la diferencia entre un programa GUI y un programa de consola? Las GUI no tienen stdin, stdout y stderr; el concepto no tiene sentido en ellos. ¿Qué pasa con los programas internos o externos a COMMAND.COM/CMD.EXE? ¿U otros motores de secuencias de comandos? ¿Qué pasa con las rutas con espacios en el nombre del comando? ¿O en los parámetros (opciones / argumentos)? (Como estás tratando de lidiar ahora ...)
Si bien no estoy 100% seguro acerca de los detalles internos o 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 corresponde). ); Se ejecuta esperando que no haya salida de la consola, ya que no es interactivo, 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 evitando el problema: el nombre del comando se toma EXACTAMENTE tal como está y los parámetros que se pasan al comando se especifican en otro cuadro de entrada en las propiedades de la tarea.
Lo que 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 a menudo incluye la ejecución de intérpretes de comandos / scripts, como CMD.EXE! Los parámetros, si los hay, se especifican en otra parte y deben conocerse cuando configura la tarea (es decir, no puede cambiar los parámetros "sobre la marcha"). Y así.
Entonces, si desea incluir parámetros, debe usar la sección de parámetros para especificar los parámetros. El programador de tareas nointente analizar el nombre del comando para dividirlo en "comando" y "argumentos" como lo hacen los programas de línea de comandos. Simplemente lo trata como un gran nombre de comando completo. Del mismo modo, si desea parámetros variables, como usar% 1 ..% n en archivos BATCH, no puede hacerlo desde el Programador de tareas; Tendrás que encontrar otra manera. (Tenga en cuenta que tampoco puede usar variables de entorno, ya que el entorno pasado al programa depende del entorno con el que se inicia la tarea, NO del entorno "actual"). Puede usar un archivo temporal para guardar los parámetros, pero ya que 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 se golpean entre sí tratando de escribir en el mismo archivo temporal al mismo tiempo, probablemente tampoco lo que querías. (También hay soluciones a este problema, pero eso va demasiado lejos del alcance de esta pregunta y respuesta ...)
Entonces, la respuesta final: en el caso simple, la ruta que desea pasar como parámetro es estática y no cambia, debe especificar los parámetros en la propiedad de Tarea apropiada (Argumentos) en lugar de en el cuadro Programa / Script , o use un archivo por lotes. En un caso más complejo, deberá hacer la pregunta correcta o investigar cómo funcionan los demonios y cómo usar el bloqueo / semáforos y demás para la comunicación entre procesos (IPC).
Buena suerte.
