Może pomóc zrozumieć problem z innej perspektywy… Powiedzmy, że jesteś programistą, któremu powierzono zadanie dodania harmonogramu zadań do systemu Windows. Jak byś to zrobił? Masz kilka problemów, z którymi musisz się zmierzyć: Jeśli zadanie jest uruchamiane jako ktoś inny niż zalogowany użytkownik, czy powinieneś denerwować zalogowanego użytkownika wyskakującymi okienkami błędów? Co zrobić, jeśli nie ma zalogowanego użytkownika w czasie, gdy zadanie jest uruchamiane? Jaka jest różnica między programem GUI a programem konsolowym? Programy GUI nie mają stdin, stdout i stderr; pojęcie to jest w nich bez znaczenia. A co z programami wewnętrznymi lub zewnętrznymi w stosunku do COMMAND.COM/CMD.EXE? Albo innymi silnikami skryptowymi? Co ze ścieżkami ze spacjami w nazwie polecenia? Lub w parametrach (opcjach/argumentach)? (Tak jak teraz próbujesz sobie z tym poradzić…)
Chociaż nie jestem w 100% pewny co do wewnętrznych lub pełnych szczegółów technicznych w tym przypadku, odpowiedzi wydają się być… Zadania są uruchamiane w odizolowanej, nieinteraktywnej sesji, która nie może wchodzić w interakcję z aktualnie zalogowanym użytkownikiem (jeśli w ogóle); Jest uruchamiany, oczekując, że nie będzie wyjścia konsoli, ponieważ jest nieinteraktywny, nie może po prostu przerwać zalogowanego użytkownika, aby pokazać wyjście, tak czy inaczej (a jeśli jest wyjście, stdin jest bitbucket/NULL, stdout i stderr są logowane do systemowego obiektu logowania); Przestrzenie są obsługiwane przez obejście problemu: nazwa polecenia jest brana EXACTLY as is, a parametry są przekazywane do polecenia są określone w innym polu wejściowym we właściwościach Task.
To wszystko oznacza, że Twoje zadanie musi być uruchamiane tak, jakby było demonem (w świecie Unlimited). Wszystko jest statyczne i precyzyjne. Nazwa polecenia jest faktyczną nazwą polecenia, bez żadnych parametrów. To często obejmuje uruchamianie interpreterów poleceń/skryptów, takich jak CMD.EXE! Parametry, jeśli istnieją, są określone gdzie indziej i muszą być znane w momencie tworzenia zadania (to znaczy, nie można zmieniać parametrów “w locie”). I tak dalej.
Tak więc, jeśli chcesz dołączyć parametry, musisz użyć sekcji parametry, aby je określić. Harmonogram zadań nie próbuje przetworzyć nazwy polecenia, aby podzielić je na “polecenie” i “argumenty”, tak jak robią to programy wiersza poleceń. Po prostu traktuje je jako jedną dużą, pełną nazwę polecenia. Podobnie, jeśli chcesz mieć zmienne parametry, takie jak użycie %1 … %n w plikach BATCH, nie możesz tego zrobić z poziomu samego Harmonogramu zadań; będziesz musiał znaleźć inny sposób. (Zauważ, że nie możesz również używać zmiennych środowiskowych, ponieważ środowisko przekazywane do programu zależy od środowiska, z którym zadanie jest uruchamiane, a nie od “bieżącego” środowiska). Możesz użyć pliku tymczasowego do zapisania parametrów, ale ponieważ musisz podać statyczną nazwę pliku we właściwościach zadania, co się stanie, gdy jesteś w sieci z 5000 użytkowników i czterech z nich spróbuje uruchomić to samo zadanie w tym samym czasie? Wszyscy oni będą się nawzajem obijać próbując pisać do tego samego pliku tymczasowego w tym samym czasie, prawdopodobnie nie jest to to, czego chciałeś. (Istnieją rozwiązania tego problemu, ale to wykracza zbyt daleko poza zakres tego pytania i odpowiedzi…)
Więc ostateczna odpowiedź: W prostym przypadku – ścieżka, którą chcesz przekazać jako parametr jest statyczna i nie zmienia się – musisz albo określić parametry w odpowiedniej właściwości Task (Arguments), a nie w polu Program/Script, albo użyć pliku wsadowego. W bardziej skomplikowanych przypadkach – będziesz musiał zadać odpowiednie pytanie lub dowiedzieć się jak działają demony i jak używać blokad/semaforów i tym podobnych do komunikacji międzyprocesowej (IPC).
Powodzenia.