cmd /c niewykonujące polecenia wskazuje na niepoprawną składnię cudzysłowów lub błąd w przekazywanym argumencie polecenia.
Jak działa przełącznik /c w interpreterze cmd.exe
Polecenie cmd /c uruchamia interpreter poleceń systemu Windows, przekazuje mu wskazany tekst, wykonuje ten tekst, a następnie kończy uruchomiony proces cmd.exe. Przełącznik /c nie jest samodzielnym poleceniem i nie naprawia składni komendy umieszczonej po nim. Jeżeli przekazany argument jest pusty, został źle podzielony przez program wywołujący albo zawiera błędy składni, interpreter może zakończyć pracę bez wykonania oczekiwanej operacji lub wyświetlić komunikat błędu.
Przykład cmd /c dir C:\Windows uruchamia wyświetlenie zawartości katalogu. W praktyce ten sam zapis może zachować się inaczej, gdy polecenie jest przekazywane z innego programu, skryptu albo skrótu. Wtedy argumenty są najpierw interpretowane przez program nadrzędny, a dopiero później przez cmd.exe. Znaki spacji, cudzysłowy, ampersand, pionowa kreska, nawiasy oraz przekierowania mogą więc zmienić granice argumentu albo sposób wykonania polecenia.
Cudzysłowy i granice argumentu po /c
Jedną z częstych przyczyn problemu jest użycie cudzysłowów w sposób, który powoduje przekazanie do cmd.exe niepełnego tekstu. Dotyczy to szczególnie ścieżek zawierających spacje, na przykład C:\Program Files. Samo wywołanie programu z taką ścieżką wymaga ujęcia jej w cudzysłów, ale połączenie ścieżki programu, przełącznika /c i właściwego polecenia tworzy dodatkową warstwę parsowania. Cudzysłów może zostać potraktowany jako element delimitujący argument, a nie jako część ścieżki, którą ma otrzymać polecenie.
Przy uruchamianiu pliku wykonywalnego ze ścieżki zawierającej spacje typową konstrukcją jest na przykład cmd /c ""C:\Program Files\Narzędzie\program.exe" argument". Zewnętrzny cudzysłów wyznacza całość tekstu przekazywanego po /c, a wewnętrzny obejmuje ścieżkę programu. Niewłaściwe ustawienie któregoś z tych znaków może sprawić, że cmd.exe spróbuje uruchomić tylko fragment ścieżki, potraktuje pozostały tekst jako osobne argumenty albo zakończy działanie przed uruchomieniem programu. W prostych przypadkach warto najpierw sprawdzić polecenie bez zagnieżdżonych cudzysłowów, a następnie dodawać je tylko tam, gdzie są potrzebne.
Znaczenie ma również różnica między przekazaniem jednego argumentu tekstowego a przekazaniem kilku argumentów rozdzielonych spacjami. Program uruchamiający może samodzielnie usuwać cudzysłowy lub inaczej dzielić wiersz polecenia. Dlatego identycznie wyglądający tekst może działać z ręcznie otwartego wiersza polecenia, ale nie działać w skrypcie, zadaniu harmonogramu albo aplikacji wywołującej proces. Diagnostyka powinna obejmować rzeczywistą wartość argumentu przekazanego do procesu, a nie tylko zapis widoczny w kodzie źródłowym.
Znaki specjalne, kod wyjścia i sprawdzanie skutku
Interpreter cmd.exe traktuje niektóre znaki jako operatory powłoki. Ampersand & rozdziela polecenia, && uruchamia kolejne polecenie po powodzeniu poprzedniego, a || robi to po jego niepowodzeniu. Pionowa kreska | przekazuje wyjście jednego polecenia na wejście drugiego, natomiast > i >> służą do przekierowania wyjścia do pliku. Nawiasy mogą grupować polecenia. Jeżeli taki znak miał być zwykłą częścią nazwy pliku lub argumentu, trzeba uwzględnić reguły cytowania i uciekania znaków właściwe dla cmd.exe. W przeciwnym razie polecenie może zostać podzielone na kilka części.
Do rozróżnienia „polecenie nie zostało uruchomione” od „polecenie uruchomiło się, ale zakończyło błędem” służy kod wyjścia procesu. Po wykonaniu komendy można sprawdzić wartość zmiennej ERRORLEVEL, na przykład poleceniem echo %ERRORLEVEL%. Trzeba jednak pamiętać, że kolejne polecenie może zmienić tę wartość, dlatego odczyt powinien nastąpić bezpośrednio po badanej operacji. W skryptach często stosuje się konstrukcje if errorlevel 1 albo zapis kodu do zmiennej, aby ocenić wynik przed wykonaniem następnych instrukcji.
Warto także sprawdzić katalog roboczy procesu, uprawnienia konta oraz dostępność programu w zmiennej środowiskowej PATH. Błąd ścieżki może wyglądać jak problem z /c, choć faktycznie interpreter nie znajduje wskazanego pliku. Pomocne jest uruchomienie prostego testu, na przykład cmd /c echo test, a następnie stopniowe dodawanie właściwej ścieżki i argumentów. Jeżeli prosty test działa, przyczyny należy szukać w cytowaniu, znakach specjalnych, katalogu roboczym lub samym programie wywoływanym przez komendę.
Postępowanie przy poleceniu, które nie wykonuje oczekiwanej operacji
Diagnostykę najlepiej rozpocząć od zapisania dokładnego wiersza polecenia oraz ustalenia, z jakiego miejsca jest uruchamiany: z interaktywnego okna, pliku .bat, programu napisanego w innym języku, skrótu czy Harmonogramu zadań. Następnie należy wykonać minimalny test z cmd /c echo test. Jeśli działa, można sprawdzić samą lokalizację programu poleceniem where nazwa_programu albo użyć pełnej ścieżki do pliku wykonywalnego. Przy ścieżkach ze spacjami trzeba przetestować wariant z prawidłowo zamkniętymi cudzysłowami.
Kolejny etap polega na rozdzieleniu elementów polecenia. Najpierw sprawdza się samo polecenie bez argumentów, później każdy argument osobno, a dopiero na końcu operatory takie jak przekierowanie lub potok. Taka kolejność pozwala ustalić, czy problem powoduje składnia polecenia, błędny plik, nieistniejący katalog, brak uprawnień czy sposób przekazania danych przez aplikację nadrzędną. W przypadku pliku wsadowego przydatne może być chwilowe dodanie echo on, aby zobaczyć wykonywane linie, oraz komunikatu diagnostycznego przed i po badanej instrukcji.
Jeżeli cmd /c uruchamia program, ale jego okno natychmiast znika, nie oznacza to automatycznie, że polecenie nie zostało wykonane. Proces może zakończyć się prawidłowo po wykonaniu zadania albo zamknąć się z powodu błędu programu. Do analizy należy zebrać komunikat wyświetlany na standardowym wyjściu i standardowym wyjściu błędów, a także kod zakończenia. Dopiero porównanie tych informacji z dokładnym argumentem przekazanym do cmd.exe pozwala wskazać rzeczywistą przyczynę.
Warszawskie Pogotowie Komputerowe wykonuje profesjonalną naprawę laptopów, komputerów PC i ich podzespołów, w tym diagnostykę problemów z uruchamianiem poleceń systemowych, konfiguracją środowiska oraz działaniem popularnego oprogramowania na komputerach użytkowych.
