Potrebbe aiutare a capire il problema da una prospettiva diversa. Supponiamo che tu sia il programmatore che è stato incaricato di aggiungere un programmatore di attività a Windows. Come lo faresti? Hai diversi problemi da affrontare: se l'attività viene eseguita come persona diversa dall'utente che ha effettuato l'accesso, dovresti infastidire l'utente che ha effettuato l'accesso con eventuali popup di errore? Che cosa succede se non ci sono utenti connessi al momento dell'esecuzione dell'attività? Che dire della differenza tra un programma GUI e un programma console? Le GUI non hanno stdin, stdout e stderr; il concetto non ha significato in loro. Che dire dei 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)? (Mentre stai cercando di affrontare ora ..)
Sebbene non sia sicuro al 100% degli interni o dei dettagli tecnici completi in questo caso, le risposte sembrano essere .. Le attività vengono eseguite in una sessione isolata, non interattiva, che non può interagire con l'utente attualmente connesso (se presente ); Viene eseguito aspettandosi che non ci sia alcun output della console, poiché non è interattivo, non può semplicemente interrompere qualsiasi utente connesso per mostrare l'output, comunque (e se c'è output, stdin è bitbucket / NULL, stdout e stderr vengono registrati su la funzione di registrazione del sistema); Gli spazi vengono gestiti ignorando il problema: il nome del comando viene preso ESATTAMENTE così com'è e i parametri passati al comando vengono specificati in un'altra casella di input nelle proprietà dell'attività.
Ciò che significa è che il tuo compito 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 parametri. Ciò include spesso l'esecuzione di interpreti di comandi / script, come CMD.EXE! I parametri, se presenti, sono specificati altrove e devono essere conosciuti quando si imposta l'attività (ovvero, non è possibile modificare i parametri "al volo"). E così via.
Quindi, se si desidera includere i parametri, è necessario utilizzare la sezione dei parametri per specificare i parametri. L'utilità di pianificazione non lo faprova ad analizzare il nome del comando per dividerlo in "comando" e "args" come fanno i programmi da riga di comando. Lo tratta solo come un grande nome di comando completo. Allo stesso modo, se vuoi parametri variabili, come usare% 1 ..% n nei file BATCH, non puoi farlo dallo stesso Utilità di pianificazione; Dovrai trovare un altro modo. (Si noti che non è possibile utilizzare le variabili di ambiente, poiché l'ambiente passato al programma dipende dall'ambiente con cui è stata avviata l'attività, NON dall'ambiente "corrente".) È possibile utilizzare un file temporaneo per salvare i parametri, ma poiché è necessario specificare un nome file statico nelle proprietà dell'attività, cosa succede quando ci si trova su una rete con 5000 utenti e quattro tentano di eseguire la stessa attività contemporaneamente? Si bloccheranno l'un l'altro cercando di scrivere nello stesso file temporaneo contemporaneamente, probabilmente neanche quello che volevi. (Esistono anche soluzioni a questo problema, ma questo va troppo al di fuori dell'ambito di questa domanda e risposta ..)
Quindi risposta finale: nel caso semplice - il percorso che si desidera passare come parametro è statico e non cambia - è necessario specificare i parametri nella proprietà Task appropriata (Argomenti) anziché nella casella Programma / Script o utilizzare un file batch. In un caso più complesso, dovrai porre la domanda giusta o fare ricerche su come funzionano i demoni e su come usare il blocco / semafori e simili per la comunicazione tra processi (IPC).
In bocca al lupo.
