ITBlog

Wprowadzenie

Środowiskiem pracy skryptów natywnych wsadowych typu BAT lub CMD systemu MS Windows jest konsola inaczej zwana wierszem poleceń czy powłoką. Aby pisać skrypty wystarczy zwykły notatnik. Jednak pisanie w nim skryptów nie jest wygodne zatem przyda się coś lepszego. Może to być program Notepad++ ale znacznie lepszym rozwiązaniem będzie Visual Studio Code z kilkoma wtyczkami. Opisano to w innym dokumencie.

Konsola systemu MS Windows

Pojęcie konsoli czy terminala pochodzi z czasów kiedy komputer ważył kilka czy kilkanaście ton a operator kontaktował się z nim za pomocą prostej klawiatury (wejście) oraz drukarki wierszowej (wyjście). To była konsola operatora a całe urządzenie był terminalem dostępowym do komputera. Widok terminala zobaczysz tutaj.

Nieco później pojawiły się monitory, które zastąpiły drukarki. W systemach operacyjnych do dziś ta idea przetrwała. Zarówno Windows jak i Linux podsiadają programy zwane konsolami czy terminalami (emulator terminala znakowego). Programy te pracują w trybie tekstowym (znakowym) i dają nam dostęp do tzw. powłoki systemu operacyjnego. Jest to interpreter poleceń, służący do zarządzania systemem. Poniżej widok standardowego terminala Windows oraz Linux.

Powłoka

Mianem tym nazywa się program działający wewnątrz terminala i świadczący różne usługi. Główną usługa jest jednak zapewnienie tekstowej komunikacji użytkownik – system operacyjny. Powłoka wspiera wiele poleceń wewnętrznych (do użycia bezpośrednio w konsoli lub w skryptach), daje także możliwość uruchamiania programów zewnętrznych. Wiele z tych programów to programy trybu tekstowego pozwalająca zarządzać systemem operacyjnym. Z powłoki można też uruchamiać programu sesji graficznej (GUI).

Przykład programu tryby tekstowego: program icacls wyświetlający uprawnienia do systemu plików

Przykład uruchomienia programu GUI:

Konsola jest w sumie jednoużytkownikowa i jednozadaniowa czyli kiedy uruchomimy w niej program trybu tekstowego to zajmie on całą konsolę i innego programu w niej w tym momencie już nie uruchomimy. Część programów (jak icacls) nie jest specjalnie interaktywnych. Uruchomi się, wykona co ma wykonać i kończy pracę tym samym zwalniając konsolę. Tak działa większość programów konsolowych systemu Windows. Ale uruchamiając np. kompresję plików za pomocą 7ZIP możemy na długie godziny konsolę zablokować. Istnieją także programy interaktywne typu TUI (ang. Text User Interface), który uruchomiony zajmuje konsolę na cały czas jego użytkowania. W tym przypadku na takiej konsoli niczego nie uruchomimy do zamknięcia programu. Oczywiście jednocześnie możemy mieć uruchomionych wiele konsol, a w każdej inny program. Taką funkcjonalność zapewnia nam powłoka graficzna systemu. Poniżej przykład menadżera plików NDN – zajmuje on całą konsolę i nie chodzi o wymiary. To tak jak dawniej w MS-DOS: uruchomienie jednego programu zajmował całą i do tego jedyną konsolę (bo innej nie było) i w sumie cały system operacyjny ponieważ był to system jednozadaniowy.

System operacyjny MS Windows jest wielozadaniowy i wieloużytkownikowy zatem może na nim jednocześnie pracować wiele programów. Zauważ więc, że przy uruchomieniu z konsoli programu GUI sama konsola jest zwalniana. Można wtedy wydawać w niej inne polecenia, uruchamiać inne programy TUI czy GUI.

Alternatywnym i ciekawym rozwiązaniem jest emulator terminala cmder.

Uruchamianie powłoki systemu

Powłokę systemu (konsolę, terminal) można uruchomić na kilka sposobów:
– Z menu Start wybieramy pozycje CMD (wiersz polecenia) lub naciskamy Win+R i wpisujemy cmd. Programem terminala jest cmd.exe.
W tym wypadku startujemy w katalogu domowym:

– Z Eksploratora plików
— uruchamiamy eksplorator plików
— przechodzimy do wybranego katalogu

 

— w pasku adresu kasujemy wpis (ścieżkę aktualnego katalogu) i wpisujemy: cmd

 

— uruchamia się nowa konsola umieszczona w katalogu, który był wcześniej wskazany w Eksploratorze plików
– Z Menadżera zadań
— uruchamiamy menadżer zadań (CTRL-SHIFT-ESC albo z konsoli polecenie taskmgr.exe)
— z menu Plik wybieramy uruchom nowe zadanie i wpisujemy cmd

 

Konsola, programy konsolowe i ich numery PID

W uruchomionej konsoli możemy prawie dowolny program czy to konsolowy czy GUI. Każda konsola (jak i każdy program a raczej proces) w systemie operacyjnym ma swój niepowtarzalny identyfikator (PID – Proces ID). Numer ten można zobaczyć na karcie Szczegóły menedżera zadań. Jednak istnieją znaczenie lepsze programy do wizualizacji całego drzewa procesów. Przykładem jest Proces Explorer z pakietu SysteInternals. Pakiet ten zawiera ogromną ilość programów diagnostycznych wiersza poleceń jak i GUI. Dla wiersza poleceń mamy program tasklist.

Uruchamiamy zatem konsolę i menadżer zadań. Jedna z naszych konsol to to na poniższej liście.

Ciekawszy widok, w postaci drzewa procesów, prezentuje Proces Explorer:

Listę procesów możemy też zobaczyć w konsoli za pomocą polecenia tasklist (MW Windows) albo pslist (SystInternals).

Aby zobaczyć tylko procesy konsoli wydamy polecenie:

> tasklist | find „cmd”

Procesy mogą uruchamiać kolejne procesy stając się ich rodzicami. W takim wypadku zamknięcie procesu rodzica powoduje zamknięcie procesu potomka. Jak pokazano wcześniej konsole można uruchamiać na kilka sposób w tym z pracującej już konsoli. Zobaczmy jaki to ma wpływ na programy. W polu Filter by name programu Process Explorer wpiszemy cmd. Jak widać żądnej konsoli jeszcze nie mamy.

Uruchamiamy teraz z menu start konsolę cmd:

Uruchomiła się konsola i ma PID=25116. Teraz uruchomimy kolejną konsolę też z menu Start. Otrzymuje ona PID=17120

Teraz uruchomimy w pierwszej konsoli program ping, który będzie działał stale

> ping 1.1.1.1 -t

Patrzymy do okna procesów i nie widzimy zmian. Powodem jest filtr. Kasujemy filtr i szukamy naszej konsoli po PID=25116:

Jest konsola jak i coś w niej uruchomione. A jest to nasz ping. Ma oczywiście swój unikalny ID ale uruchomiony został w ramach konsoli, co pokazuje struktura drzewa. W każdej konsoli widzimy też jeszcze inny proces, którego nie uruchamialiśmy. To automatycznie tworzony proces wspomagający pracę w tekstowym trybie użytkownika. Zamykamy teraz to  okno konsoli (przez naciśnięcie X). Zarówno polecenie ping jak i konsola i conhost znikają. Pokazuje to zależność procesów rodzić – dziecko. Taka zależność występuje gdy proces potomny wymaga obecności procesu nadrzędnego.

Procesy niezależne

Część programów, które możemy uruchomić w konsoli, zostanie po uruchomieniu „oddzielona” od niej. Od tego momentu praca konsoli jak i takiego programu będą niezależne. Przykładem jest Microsoft Management Console (mmc.exe). Wracamy do naszej konsoli PID=17120 (bo ta druga już zamknęliśmy) i uruchamiamy w niej mmc.exe. Program MMC się uruchamia:

Zamykamy teraz konsolę PID=17120 i widzimy, że ten program nie został zamknięty jak ping. Ponieważ jest to program GUI praca samej konsoli juz nie jest mu potrzebna.

Konsola w konsoli

Otwieramy nową konsolę i szukamy jej w drzewie procesów.

Teraz w tej konsoli wpiszemy cmd i kiedy pojawi się nowy wiersz zachęty znowu wpiszemy cmd i raz jeszcze. Za każdym razem uruchomi się nowa sesja/powłoka ale w tej samej konsoli rodzica.

Zamknięcie powłoki nadrzędnej (PID=2192) spowoduje zamknięcie wszystkich potomnych powłok tej sesji konsoli. Aby opuścić taką pod-sesję można wydać polecenie exit. Popatrzmy na na nasze drzewo procesów powyżej: ostatnia sesja powłoki na PID=15532. Jeśli w tej sesji wydamy polecenie

To z drzewa znika ostatnio uruchomiona sesja:

Konsola i skrypty

Kiedy uruchamiamy skrypt w konsoli, pracuje on w jej środowisku (chyba, że w skrypcie uruchomimy kolejną powłokę, co było pokazane wcześniej). Napiszemy prosty skrypt pętli zliczającej do 10000, uruchomimy go i w drzewie procesów zobaczymy czy pracuje on w nowej powłoce.

– uruchamiamy wiersz polecenia, sprawdzamy jaki ma PID (tutaj 19648)
– w tej konsolo uruchamiamy nasz skrypt:

Uruchomienie skryptu nie powoduje uruchomienia nowej powłoki.

Praca z terminalem

W tym przypadku wszelkie polecenie wydajemy z klawiatury. Poleceń jest ogromna ilość i dzielą się na wewnętrzne i zewnętrzne. Polecenia wewnętrzne są wbudowane w powłokę. Przykładem jest cls służące do czyszczenia ekranu. Plecenia zewnętrzne to programy (w postaci plików) wspomagające pracę systemu. Przykładem jest tasklist wyświetlający listę procesów.

Aby przechodzić między wprowadzanymi w sesji powłoki poleceniami użyjemy strzałki w górę i w dół. Aby skopiować coś z konsoli do schowka zaznaczamy myszą tekst i klikamy jej prawym klawiszem. Aby wkleić tekst ze schowka, ustawiamy kursor w wybranym miejscu i klikamy prawym klawiszem myszki. Jeśli wydane polecenie wygeneruje wiele ekranów możemy je przewijać.

Wyświetlanie ekran po ekranie
Możemy także wstrzymać wyświetlanie tekstu co ekran za pomocą potoku poleceniem program | more. Przykład: pomoc konsoli: help. Wyświetli kilka ekranów i nawet ich nie zobaczymy, tak szybko sie wszystko przewinie. Wydając polecenie help | more możemy czytać ekran po ekranie.

Aby w generowanym przez program tekście wyszukać wiersze zawierające wybraną frazę użyjemy polecenia find: help | find „CD”

Aby generowany przez program konsolowy tekst zapisać do pliku użyjemy przekierowania strumienia:

>help > pomoc.txt

Po wydaniu polecenia w aktualnym katalogu pojawia sie plik pomoc.txt Listę poleceń systemu Windows znajdziesz tutaj.

Rodzaje skryptów powłoki Windows

Mamy dwa rodzaje natywnych skryptów powłoki systemu MS Windows: pliki typu BAT oraz pliki CMD. Pierwsze pochodzą z przed ponad 40 lat i pojawiły się w MS-DOS jako pliki przetwarzania wsadowego. Jest to sposób wydawania poleceń komputerowi bez interakcji (choć i taka może tu się pojawić, zależy jak taki kod napiszemy). Jest on wielce przydatny w automatyzacji zarządzania systemami operacyjnymi. Drugi rodzaj plików to pliki dla nowych systemów MS Windows. Oba działają bardzo podobnie i oba możemy używać. Tutaj nieco informacji o różnicach.

Zmienne systemowe

Oba rodzaje skryptów potrafią korzystać ze zmiennych systemowych, które istnieją w Windows. Zmienne te można zobaczyć wydając polecenie konsoli set:

 

Każda zmienna ma swoją nazwę i wartość. Wartość zmiennej można wyświetlić za pomocą polecenia:

> echo %NAZWAZMINNEJ%

Przykład: zobaczmy jak się nazywa maszyna na której pracujemy oraz jaką nazwę ma nasze konto:

Wielkość liter nie ma znaczenia ale przyjęło się pisać dużymi.

Aby ustawić nową zmienną wydać należy polecenie set NAZWAZMIENNEJ = WAROTŚĆ

Aby ją usunąć:

> set DANE=

Uwaga: tak utworzone zmienne istnieją tylko i wyłącznie w aktualnej powłoce (oknie cmd). Jeśli ją zamkniemy tracimy wszelkie utworzone w ten sposób zmienne. W systemie operacyjnym istnieje wiele zmiennych a my sami możemy tworzyć nowe i sprawić aby były dostępne między powłokami a nawet między restartami komputera.

Aby utworzyć nową zmienną (tylko dla swojego aktualnego konta) wydać należy polecenie:

> setx NAZWAZMIENNEJ WAROSC /m

Ustawianie na stałe zmiennych systemowych użytkownika

Aby ustawić swoje zmienne systemowe, które dostępne będą między powłokami jaki i między uruchomieniami komputera możemy wydać polecenie:

> rundll32.exe sysdm.cpl,EditEnvironmentVariables

Pojawi się okno konfiguracyjne, a w jego górnej części możemy edytować nasze zmienne. Są one dostępne przez wszystkie konsole i skrypty w naszej sesji logowania.

Sprawdźmy jak to działa. Otwieramy konsolę i sprawdzamy jaka wartość ma zmienna _DANE_

echo %_DANE_%

Jeśli w odpowiedzi dostajemy %NAZWA% to znaczy, że takiej zmiennej nie ma w systemie. Dodamy ją przez powyższe okno:
– klikamy Nowa
– podajemy nazwę zmiennej jak i jej wartość

– zatwierdzamy
– otwieramy nowe okno konsoli
– sprawdzamy nasza zmienną

– od teraz w każdej sesji konsoli zmienna już jest dostępna

Rodzaje zmiennych ze względu na zakres obowiązywania

Zmienne mogą być globalne i lokalne w stosunku do skryptu powłoki. Kiedy uruchamiamy skrypt, możemy w nim używać zmiennych systemowych (globalnych) oraz tworzyć nowe. Kiedy tworzymy nową zmienna w skrypcie a on kończy pracę to ta zmienna zostaje już w aktualnej powłoce. Nie zawsze będzie to dobra sytuacja ponieważ kolejny skrypt może używać zmiennej o identycznej nazwie ale innej zawartości. Poniżej omówiono zmienne lokalne i globalne ale: to są zmienne utworzone w skrypcie i obowiązujące tylko w sesji powłoki, w której działa skrypt. Tych zmiennych nie zobaczymy w innych sesjach powłoki czyli w innych oknach cmd.

Zmienne globalne
Uruchamiany nową konsolę. Sprawdzamy czy istnieje zmienna _MOJE-DANE_. Nie istnieje.

Tworzymy skrypt zmienne1.cmd o zawartości:

Uruchamiamy skrypt i ponownie sprawdzamy czy zmienna istnieje:

Tak, teraz ta zmienna jest dostępna nawet po zakończeniu działania skryptu. Tworzymy zatem drugi skrypt zmienne2.cmd i sprawdzamy w nim czy ta zmienna będzie dostępna:

Tak, ta zmienna jest teraz dostępna w skryptach ponieważ jest to zmienna globalna względem TEJ konsoli i TEJ powłoki, w której pracujemy. Nie zawsze będzie to pożądane. Zatem teraz coś o zmiennych lokalnych.

Zmienne lokalne
To identyczna zmienna jak wcześniej ale ma zakres obowiązywania tylko w obszarze skryptu, w którym została utworzona. Napiszemy kolejny skrypt zmienne3.cmd:

 

Oraz wynik działania na konsoli:

Przykład zmiennej systemowej PATH

Wśród wielu zmiennych systemowych bardzo ważną jest zmienna o nazwie PATH. Jest to tzw. ścieżka poszukiwań czyli zestaw katalogów, które są przeszukiwane przez system operacyjny celem znalezienia pliku. Jaki to pliku to już zależy od polecenia czy kontekstu. Przykładowo uruchamiamy z wiersza poleceń program mmc.exe (Microsoft Management Console) jak niżej:

Program się bez problemu uruchomi. Jednak jest pytanie: gdzie znajduje się plik mmc.exe. Wyświetlając katalog bieżący nie widzimy go:

Plik ten (jak i wiele innych) znajduje się w katalogu c:\windows\system32. Zatem jak on sie uruchomił? Odpowiedzią jest proces w jaki jest taki program poszukiwany. Kiedy w wierszu polecenia wpisujemy coś to powłoka stara się sprawdzić czy to polecenie wewnętrzne czy program. Jeśli polecenie wewnętrzne to jest ono uruchamiane natychmiast. Jeśli to program to system Windows szuka go w katalogu bieżącym. Jeśli znajdzie to uruchamia, jeśli nie przystępuje do przeszukiwania kolejnych katalogów umieszczonych w zmiennej PATH. Poniżej jej przykładowy widok:

Ta zmienna zawiera wiele katalogów oddzielonych średnikiem. Kiedy system napotka na katalog w którym jest uruchamiany plik uruchamia go i tyle. Kiedy zostaną przeszukane wszystkie katalogi w tej zmiennej ale w żadnym pliku nie będzie system poinformuje o tym wyświetlając błąd:

Zwróć uwagę, że system przekazał informację, iż podana fraza to nie jest: polecenie wewnętrzne powłoki, program czy skrypt wsadowy. Ta kolejność nie jest bez powodu!

Kolejność / priorytet uruchamiania plików wykonywalnych

W systemie MS Windows możemy znaleźć kilka rodzajów plików uruchamialnych. Aby taki plik uruchomić nie trzeba podawać jego rozszerzenia. Wygodne ale może prowadzić do nieporozumień i błędów. Poniżej pliki wykonywalne w MS Windows:

binarne
– .exe
– .com
– .msi

wsadowe
– .bat
– .cmd
– .ps1

Plików z rozszerzeniem .com już raczej nie spotkasz ponieważ były popularne pod MS-DOS i pierwszymi Windowsami.

Co się stanie gdy w jednym katalogu mamy sześć plików wykonywalnych o tej samej nazwie ale innym rozszerzeniu (i oczywiście zawartości). Sprawdźmy to!

Tworzymy plik wsadowy program.bat o zawartości

Możemy w notatniku albo z konsoli (jak prawdziwy pros):

> echo @echo off > program.bat
> echo echo To jest plik wsadowy BAT >> program.bat

Tworzymy plik wsadowy program.cmd o zawartości

Tworzymy plik PowerShell (też w sumie wsadowy) o nazwie program.ps1

Teraz czas na pliki wykonywalne.

Pliku program.com raczej na komputerze możesz nie mieć więc tutaj jest do pobrania. To program napisany w asemblerze i skompilowany do .COM, wyświetla na ekranie napis Hello Word. Tego programu nie uruchomisz na Windows 8 i nowszych ale pokaż się okno ostrzeżenia jak niżej:

Plik .exe to dowolny plik z Twojego komputera. Skopiuj cokolwiek do bieżącego katalogu i zmień nazwę na program.exe (w eksploratorze plików prawym myszki i Zmień nazwę albo zaznacz plik i naciśnij klawisz F2). Możesz skopiować c:\Windows\System32\cmd.exe

Plik .msi to instalator dowolnego programu, mały plik to archiwizator 7ZIP, pobierz go i zmień nazwę na program.msi. Link masz tutaj.

Przykładowy katalog wygląda tak:

Odpalamy w nim konsole cmd i wydajemy polecenie uruchomienia programu o nazwie „program”. Co sie uruchomi?

W moim przypadku uruchomił się program.com! To by oznaczało, że ten format pliku wykonywalnego ma pod MS Windows najwyższy priorytet. Jakaś nostalgia Billa do MS-DOSa z lat 80? Zmienimy teraz nazwę tego pliku na coś innego (aby nie był brany pod uwagę) i ponownie wydamy polecenie „program”:

Teraz system operacyjny próbował uruchomić plik .exe. Nie widzimy tego teraz ale uruchomiła sie nowa powłoka w aktualnej. Wydaj polecenie exit i wrócisz do poprzedniej. To ważne ponieważ musimy teraz zmienić nazwę pliku program.exe. Zatem teraz zmienimy nazwę pliku progra.exe i dalej testujemy.

Teraz jest uruchamiany plik BAT. Znowu zmienimy jego nazwę i ponownie uruchamiamy. Teraz uruchomi sie plik CMD

Jeśli teraz zmienimy nazwę pliku program.cmd to w kolejnej próbie nic już sie nie uruchomi.

Jeśli teraz spróbujemy w naszym katalogu w plikami program.* uruchomić wiersz poleceń PowerShell i wydać poleceni program to nic się nie uruchomi. Dopiero po wydaniu polecenia .\program uruchomi się skrypt PS

Konsola PS działa tak, że nawet jeśli skrypt jaki chcemy uruchomić jest w aktualnym katalogu to i tak go nie uruchomimy wpisując jego nazwę jak to było w poprzednich przypadkach czyli w konsoli natywnej powłoki. Tutaj to działa trochę jak w Linux: albo podamy pełną ścieżkę do pliku skryptu (rozszerzenia ps1 nie trzeba podawać) albo możemy uruchomić plik z aktualnego katalogu ale za pomocą dodatkowych znaków” .\