Dlaczego cmd nie kończy pracy po wykonaniu pliku wsadowego?

Jeśli aplikacja Java nie kończy się (np. używasz pliku wsadowego do uruchomienia aplikacji Java), użyj polecenia start, aby ją uruchomić:-

start "" "C:\Program Files (x86)\Java\jre6\bin\javaw.exe" -Xmx1024M -Xms1024M -jar Jilko.jar

To uruchomi aplikację Java i będzie kontynuować wykonywanie pliku wsadowego bez czekania na zakończenie aplikacji Java.

Objaśnienie:

Oto jak to działa; plik wsadowy jest przetwarzany po jednej linii na raz. Każde polecenie jest wykonywane po kolei, a procesor wsadowy czeka na zakończenie jednego polecenia przed rozpoczęciem następnego. Problem, którego doświadczasz, jest spowodowany tym, że aplikacja Java, którą uruchamiasz (Jilko.jar), jest programem okienkowym, który kontynuuje działanie nawet po uruchomieniu wiersza, który go uruchamia. Jeśli byłoby to narzędzie, które wykonuje jakąś akcję i kończy pracę, plik wsadowy kontynuowałby do następnego polecenia (lub zakończyłby pracę, jeśli nie ma więcej). Ponieważ program jest nadal uruchomiony, procesor wsadowy czeka, aż okno zostanie zamknięte, zanim przejdzie dalej. Można to zobaczyć w działaniu, kończąc program Java: okno konsoli z plikiem wsadowym zostanie zamknięte.

Rozwiązanie:

To, co musisz zrobić, aby to naprawić, to poinstruować procesor wsadowy, aby uruchomił program i kontynuował bez czekania:

start "" "C:\Program Files (x86)\Java\jre6\bin\javaw.exe" -Xmx1024M -Xms1024M -jar Jilko.jar

Jak Terrance wspomniał , "" jest tytułem, którego należy użyć dla okna konsoli. Jest on jednak opcjonalny tylko wtedy, gdy polecenie nie jest w cudzysłowie; w przeciwnym razie jest wymagany. Możesz wstawić tam coś, jeśli chcesz, lub pozostawić puste, ale jeśli polecenie jest w cudzysłowie, musi być obecne, w przeciwnym razie interpreter poleceń potraktuje zacytowane polecenie jako tytuł i otworzy konsolę, która po prostu siedzi tam czekając na coś do zrobienia.

Zamiast tego można użyć czegoś w rodzaju poniższego polecenia, ale cudzysłów jest po prostu łatwiejszy i bezpieczniejszy, gdyż nie ma gwarancji, że nazwy skrócone będą takie same w każdym systemie.

start C:\Progra~2\Java\jre6\bin\javaw.exe -Xmx1024M -Xms1024M -jar Jilko.jar

Polecenie start jest wbudowanym poleceniem, które wywołuje proces (w zasadzie jak uruchamianie programu z menu Start). Tak więc w tym kontekście procesor wsadowy uruchamia polecenie start, które z kolei uruchamia określony program i kończy pracę (sam, a nie program wywołany). W związku z tym procesor wsadowy kontynuuje pracę zgodnie z oczekiwaniami. Ma też pewne opcje, które mogą być przydatne, takie jak uruchamianie programu zminimalizowanego (/min) lub zmaksymalizowanego (/max), uruchamianie go z niskim priorytetem (/low) i tak dalej. Zobacz start /? po szczegóły.

Odkryłem, że niektóre z programów, które uruchamiam, pozostawiają uruchomione procesy, a okno konsoli nie zamknie się, dopóki nie zakończą się, jeśli po prostu uruchomię je przez uruchomienie pliku wykonywalnego.

Program START naprawia to, ale stary problem z START jest nadal aktualny. Nie możesz po prostu użyć:

START "c:\my dir\myfile.exe"

Pierwszym parametrem START jest nadal nazwa okna. Jeśli go pominiesz, po prostu otworzysz okno konsoli CMD z oknem o nazwie, którą próbowałeś uruchomić. W powyższym przypadku, miałbym teraz okno konsoli z tytułem okna “c:my dirthile.exe”. Nie tego chciałem!

Aby pominąć nazwę okna, wystarczy użyć pary podwójnych cudzysłowów do zdefiniowania pustego łańcucha, np:

START "" "c:\my dir\myfile.exe"

Na koniec zakończ swój plik wsadowy poleceniem EXIT, aby zapewnić jego zamknięcie.

Ta metoda wydaje się działać konsekwentnie w systemach Windows 7 i 8.

Przy rozwiązywaniu problemów, uważam, że dodanie ECHO tego, co mam zamiar zrobić, a następnie TIMEOUT tego, co właśnie zrobiłem, bardzo pomaga. Na przykład:

ECHO I'm about to launch the program...
START "" "c:\my dir\myfile.exe"
TIMEOUT 5

Ponieważ Timeout daje ci odliczanie, nie musisz ECHO, że masz zamiar opóźnić.

Ponadto – używaj EXIT zawsze,pod Windows 7, ponieważ samo dotarcie do końca pliku wsadowego niekoniecznie kończy jego działanie – jak we wcześniejszych wersjach Windows. Windows 7 może być na to bardziej wrażliwy niż wcześniejsze wersje NT (np. Windows 2000 Professional). Zostało to wspomniane w niektórych, ale nie wszystkich poprzednich odpowiedziach.

Szczegóły osobistego doświadczenia, aby poprzeć odpowiedź:

Po przeniesieniu instalacji StarOffice5.2 z Windows 2000 do Windows 7, otrzymywałem błędy przestrzeni pamięci po zamknięciu pakietu. Nie było to widoczne w Windows 2000.

Lata temu napisałem pliki wsadowe do automatycznego tworzenia kopii zapasowych i przywracania pliku soffice.ini, aby umożliwić jego naprawę, gdy zostanie uszkodzony (co jest na tyle częste, że stanowi problem - pakiet nie ładuje się). Automatyczna kopia zapasowa (uruchamiana przez łącze do pliku wsadowego, umieszczonego w Office52) pojawia się jednak dopiero po około 5-sekundowym opóźnieniu. Zauważyłem, że za każdym razem, gdy kończyłem pracę z pakietem tuż przed uruchomieniem pliku wsadowego, zakończenie pracy z pakietem przebiegało bezbłędnie. To wskazało mi na problem w plikach wsadowych.

Po umieszczeniu komendy ‘EXIT’ jako ostatniej linii w plikach wsadowych, pakiet biurowy zaczął kończyć pracę bez komunikatów o błędach przestrzeni pamięci, przez cały czas, niezależnie od tego czy pliki wsadowe zostały uruchomione czy nie.

Właśnie miałem do czynienia z tym samym problemem i w końcu rozwiązał się po wprowadzeniu czegoś, co wydawało się losowymi zmianami w pliku wsadowym - nie rozumiem dlaczego, ale opublikuję go tutaj na wypadek, gdyby to pomogło komuś innemu później.

Używam narzędzia SysInternals Pskill i narzędzia sleep ponieważ XP Home nie zawiera zbyt wiele funkcji wiersza poleceń.

To jest plik wsadowy, który jest zamykany po zakończeniu pracy:

@echo off
start /min C:\Progra~1\PsTools\pskill.exe explorer.exe
start /min C:\Progra~1\PsTools\pskill.exe Powermenu.exe
start /min C:\Progra~1\PsTools\pskill.exe PWGen.exe
start /min C:\Progra~1\PsTools\pskill.exe redshiftgui.exe
start /min C:\Progra~1\PsTools\pskill.exe clipx.exe
sleep 2
start explorer.exe
sleep 3
start C:\Progra~1\ClipX\clipx.exe
sleep 1
start C:\Progra~1\Powermenu\PowerMenu.exe
sleep 1
start /min C:\Progra~1\PWGen\PWGen.exe
sleep 1
start C:\Progra~1\RedshiftGUI\redshiftgui.exe && exit

Gdybym tak zmienił kilka ostatnich linijek, okno cmd pozostawałoby otwarte, dopóki nie kliknąłbym ‘X’ w rogu:

start C:\Progra~1\RedshiftGUI\redshiftgui.exe
sleep 1
start /min C:\Progra~1\PWGen\PWGen.exe && exit

Nawet gdybym próbował wywołać pskill, aby sam się zabił, proces cmd.exe zniknąłby z Menedżera zadań, a pskill zgłosiłby z wnętrza swojego cmd. exe, że proces cmd.exe został zabity, ale okno cmd.exe wciąż pozostawało otwarte, dopóki nie kliknąłem ‘X’ w rogu:

start C:\Progra~1\RedshiftGUI\redshiftgui.exe
sleep 1
start /min C:\Progra~1\PWGen\PWGen.exe
sleep 1
C:\Progra~1\PsTools\pskill.exe cmd.exe

Po dodaniu && exit do każdej linii zauważyłem, że niektóre z nich reagują na to i przerywają przetwarzanie wsadowe, podczas gdy inne nie.

Więc po prostu umieściłem jeden z tych reagujących na końcu zamiast tego, jak miałem to pierwotnie.

Jak już powiedziałem, nie wiem dlaczego, ale cieszę się, że to się skończyło.

Po zakończeniu pracy aplikacja powinna się zamknąć. Czy jesteś pewien, że aplikacja Java kończy pracę prawidłowo?

próbować:

cmd /c "C:\Program Files (x86)\Java\jre6\bin\javaw.exe" -Xmx1024M -Xms1024M -jar Jilko.jar

Windows 2003 domyślnie nie ma “Konta użytkowników” w Panelu Sterowania. Napisałem krótki batch, aby otworzyć Konta użytkowników:

@echo off  
rundll32.exe %SystemRoot%\system32\netplwiz.dll,UsersRunDll  
exit

To działało OK, Konta Użytkowników otworzyły się, ale okno CMD pozostało również otwarte. Po kilku poszukiwaniach tutaj, dodałem: START “” na początku linii 2 w ten sposób:

@echo off  
Start "" rundll32.exe %SystemRoot%\system32\netplwiz.dll,UsersRunDll o
exit

Teraz okno Konta użytkownika otwiera się, pozostaje otwarte, a okno CMD zamyka się. Łatwizna.

Szukałem i szukałem rozwiązania, aby zamknąć okno pliku wsadowego, gdy polecenie EXIT pozostawia okno otwarte z nieznanego powodu. W końcu natknąłem się na rozwiązanie.

Usuń EXIT z końca pliku wsadowego i użyj:

Taskkill /IM conhost.exe /F
```.

Utworzyłem plik wsadowy net use na 32-bitowym komputerze z systemem Windows 7 i cmd pliku wsadowego nie zamyka się po wykonaniu. Uruchomiłem ten sam plik wsadowy na innym komputerze z systemem Windows 7 64-bitowym, a cmd pliku wsadowego kończy się normalnie.

Próbowałem sugestia Bryana i to nie działa na tym Windows 7 32-bitowym komputerze, ponieważ nie było tam procesu conhost.exe, więc zmodyfikowałem go w następujący sposób:

Taskkill /IM cmd.exe /F

Plik wsadowy net use nie zawsze kończy się normalnie i pokazuje potwierdzenie “Terminate batch job (Y/N)” randomly.

Zgodnie z tym wątkiem zmodyfikowałem plik wsadowy w następujący sposób:

@echo off

if "%~1"=="-FIXED_CTRL_C" (
   REM Remove the -FIXED_CTRL_C parameter
   SHIFT
) ELSE (
   REM Run the batch with <NUL and -FIXED_CTRL_C
   CALL <NUL %0 -FIXED_CTRL_C %*
   GOTO :EOF
)

net use \Server\folder

Taskkill /IM cmd.exe /F

The net use batch file eventually exit normally.

Oto jak to zrobiłem:

1. Utwórz plik wsadowy o następującej zawartości:

2. W strumieniu wejściowym wyjścia dodaj: