Potrebbe aiutare a capire il problema da una prospettiva diversa. Diciamo che tu sei il programmatore che è stato incaricato di aggiungere un task scheduler a Windows. Come lo fareste? Avete diversi problemi da affrontare: Se il compito viene eseguito come qualcuno diverso dall'utente loggato, dovreste infastidire l'utente loggato con qualche popup di errore? Cosa succede se non c'è un utente loggato nel momento in cui il task viene eseguito? E la differenza tra un programma GUI e un programma da console? Le GUI non hanno stdin, stdout e stderr; il concetto non ha senso in esse. E i programmi interni o esterni a COMMAND.COM/CMD.EXE? O altri motori di scripting? Che dire dei percorsi con spazi nel nome del comando? O nei parametri (opzioni/argomenti)? (Come stai cercando di fare ora..)
Mentre non sono sicuro al 100% degli interni o dei dettagli tecnici completi in questo caso, le risposte sembrano essere. I task vengono eseguiti in una sessione isolata, non interattiva, che non può interagire con l'utente attualmente loggato (se c'è); Viene eseguito aspettandosi che non ci sia alcun output di console, poiché è non interattivo, non può semplicemente interrompere qualsiasi utente loggato per mostrare l'output, in ogni caso (e se c'è output, stdin è il bitbucket/NULL, stdout e stderr vengono registrati nella struttura di logging del sistema); Gli spazi vengono gestiti bypassando il problema: il nome del comando è preso ESATTAMENTE così com'è, e i parametri sono passati al comando sono specificati in un'altra casella di input nelle proprietà del Task.
Ciò che significa è che il vostro task deve essere eseguito come se fosse un demone (nel mondo Un*x). Tutto è statico e preciso. Il nome del comando è il nome effettivo del comando, senza alcun parametro. Questo spesso include l'esecuzione di interpreti di comandi/script, come CMD.EXE! I parametri, se ce ne sono, sono specificati altrove, e devono essere noti quando si imposta il compito (cioè, non si possono cambiare i parametri “al volo”). E così via.
Quindi, se volete includere dei parametri, dovete usare la sezione dei parametri per specificarli. Il Task Scheduler non cerca di analizzare il nome del comando per dividerlo in “command” e “args” come fanno i programmi a riga di comando. Lo tratta semplicemente come un grande nome di comando completo. Allo stesso modo, se volete parametri variabili, come usare %1 .. %n nei file BATCH, non potete farlo dal Task Scheduler stesso; dovrete trovare un altro modo. (Notate che non potete nemmeno usare variabili d'ambiente, poiché l'ambiente passato al programma dipende dall'ambiente con cui il task viene avviato, NON dall'ambiente “attuale”). Potresti usare un file temporaneo per salvare i parametri, ma dato che devi specificare un nome di file statico nelle proprietà del task, cosa succede quando sei su una rete con 5000 utenti e quattro di loro cercano di eseguire lo stesso task allo stesso tempo? Si scontreranno tutti tra loro cercando di scrivere sullo stesso file temporaneo nello stesso momento, probabilmente non è quello che volevi. (Ci sono anche soluzioni a questo problema, ma questo va troppo oltre lo scopo di questa domanda e risposta…)
Quindi risposta finale: Nel caso semplice – il percorso che vuoi passare come parametro è statico e non cambia – devi o specificare i parametri nella proprietà appropriata di Task (Arguments) piuttosto che nella casella Program/Script, o usare un file batch. In un caso più complesso – dovrai fare la domanda giusta o ricercare come funzionano i demoni e come usare locking/semaphores e simili per la comunicazione tra processi (IPC).
Buona fortuna.