SKRYPTY PISANE W JĘZYKU POWŁOKI (CMD.EXE)
Skrypty w Windows2000/XP, aby wykonane były przez interpreter poleceń cmd.exe muszą mieć rozszerzenia .cmd lub .bat.
Polecenia wiersza poleceń wykorzystywane w skryptach szeroko opisane są w pomocy systemu Windows. Znajdziemy też opis przydatnych instrukcji: if, for, goto, call, echo itd.
Pliki wsadowe i użyteczne zmienne środowiska pracy
Jeśli pisanie skryptów logowania w jakimś trudnym języku wygląda jak strzelanie z armaty do wróbli, można wykorzystać pliki wsadowe (batch files). Za pomocą interpretatora poleceń (command interpreter) CMD tworzy się całkiem wymyślne pliki wsadowe.
Niektórzy znawcy potrafiliby chyba stworzyć kompletny system operacyjny posługując się wyłącznie plikiem wsadowym. W pliku wsadowym nie można stosować wyszukanych pętli programowych i programowania strukturalnego, ale do nadawania wartości zmiennym środowiska pracy lub mapowania kilku dysków plik taki nadaje się znacznie lepiej niż skrypt VB.
Uruchamianie starszych skryptów w systemie Windows 2000
System Windows 2000 automatycznie uruchamia w tle w komputerze-kliencie skrypty z rozszerzeniami BAT i CMD. Jest to prawdą nawet jeśli w skrypcie umieszczone są tylko przerwania (break), aby zatrzymać go podczas wyświetlania na ekranie.
Jeśli plik wsadowy lub plik poleceń (command flle) ma być wyświetlany na ekranie, należy aktywować następujące założenia grupowe (group policy):
User Configuration|Administrative Templates|System|l_ogon/Logoff|Run Logon Scripts Visible
Kilka zmiennych środowiskowych może być przydatnych do pisania skryptów zarządzających kontami użytkowników. Oto ich lista:
■ USERPROFILE. Ścieżka dostępu do lokalnego profilu użytkownika, typowo jest to C:\Documents and Settings\<nazwa_użytkownika>.
■ ALLUSERSPROFILE. Ścieżka dostępu do profilu^// Users. Typowo jest to C:\Documents andSettings\All Users.
■ COMPUTERNAME. Nazwa NetBIOS komputera, do którego załogował się użytkownik.
■ HOMEDRIVE. Symbol (litera) dysku wykorzystywana do mapowania do katalogudomowego.
■ HOMEPATH. Pełna ścieżka UNC do katalogu domowego.
■ LOGONSERYER. Nazwa NetBIOS serwera identyfikującego użytkowników.
■ OS. System operacyjny zainstalowany w komputerze użytkownika.
■ USERDOMAIN. Domena identyfikująca użytkownika.
■ USERNAME. Nazwa NetBIOS użytkownika.
Informację o zmiennych uzyskamy korzystając z polecenia: SET
Poniżej znajduje się plik wsadowy wykorzystujący te zmienne:
@echo off
echo Hello. %USERNAMES%. Welcome to the %USERDOMAIN% domain.
Echo You have logged on to %LOGONSERVER% z %COMPUTERNAME%
Echo You are running %QS% from the %SYSTEMROOT% directory.
Echo Your home directory is on %homedrive%%homepath%.
Echo The path to this directory is %homeshare%%homepath%
Echo Your local settings are located in %USERPR0FILE%.
Echo Additional settings are located in %ALLUSERSPROFILE%.
Wynik wykonania powyższego pliku może wyglądać następująco:
Hello. Rmanuel. Welcome to the Company.com domain.
You have logged on to PHX-DC-01 from PHX-W2KP-032.
You are running Windows_NT from the \WINNT directory.
Your home directory is Z:\RMANUEL
The path to this directory is \\phx-dc-01\usres.
Your local settings are stored in C:\Documents and Settings\Administrator [PHX-W2KP-001].
Additional settings are located in C:\Documents and Settings\All Users.
Konfigurowanie interpretatorów poleceń
Nieważne, jak funkcjonalny i wygodny wydaje się graficzny interfejs użytkownika systemu Windows 2000. Nieuchronnie nadejdzie czas, kiedy okaże się, że do wykonania rzeczywistej pracy potrzebny jest wiersz poleceń. W systemie Windows NT są dwa okna konsoli: 32-bitowej konsoli wykorzystującej CMD.EXE jako interpretator poleceń i konsoli 16-bitowej wykorzystującej COMMAND.COM jako interpretator. Konsola COMMAND.COM zapewnia środowisko pracy z poleceniami DOS 5.0 umożliwiającymi uruchamianie plików wykonywalnych i programów rezydentnych (TSR), które wymagają prawdziwego środowiska DOS.
Konsole CMD i COMMAND nie umożliwiają pracy w środowisku DOS w takim sensie, jak występuje to w systemie OS/2 w postaci procesu o nazwie „DOS box". Konsola CMD jest programem 32-bitowym i tworzy prawdziwe 32-bitowe środowisko pracy. Konsola COMMAND.COM pracuje w środowisku wirtualnego komputera DOS-owego (VDM), ale w razie potrzeby bezkolizyjnie przechodzi do 32-bitowego interpretatora poleceń CMD. Uruchomienie z konsoli COMMAND na przykład polecenia DIR, spowoduje wyświetlenie na ekranie długich nazw plików (long filenames), a nie krótkich.
Konsole alternatywne
System Windows 2000 zawiera dwie rzadko używane konsole. Jedną dla standardu POSIX, drugą dla systemu OS/2. Obsługa standardu POSIX w systemie Windows NT spełnia wymagania rządowe, ale programy spoza systemu Windows, takie jak MKS Toolkit lub Reflections, zapewniają zazwyczaj bardziej wszechstronną obsługę Uniksa. Konsola systemu OS/2 obsługuje tylko aplikacje tekstowe wersji 1.1 i przez to jest straszliwie przestarzała. Obsługa systemu OS/2 przez Windows 2000 jest jak stara fotografia ślubna poniewierająca się w albumie długo po rozwodzie. Firma Microsoft nie chce pozbyć się jej, chociaż służy tylko do przywoływania przykrych wspomnień.
Uruchamianie wiersza poleceń za pomocą pozycji menu START\PROGRAMY\WIERSZ POLECEŃ (START\PROGRAMS\COMMAND PROMPT) w rzeczywistości powoduje uruchomienie 32-bitowej konsoli CMD. Można to sprawdzić otwierając Menedżera zadań (Task Manager) i wybierając zakładkę Processes (Procesy). CMD.EXE znajduje się na liście uruchomionych zadań. Jeśli w komputerze zainstalowano Resource Kit, można sprawdzić listę uruchomionych procesów za pomocą programu TLIST/t. Kiedy uruchamia się aplikację 16-bitową, system Windows 2000 najpierw uruchamia NTVDM.EXE, a następnie ładuje aplikację do środowiska wirtualnego komputera DOS-owego (VDM). Jeśli aplikacja 16-bitowa jest uruchamiana z konsoli CMD, 'NTVDM.EXE jest wątkiem (thread) CMD.
Możliwość uruchamiania w tle konsoli CMD przez konsolę COMMAND, umożliwia również uruchamianie 32-bitowych aplikacji graficznych. Na przykład otwórz konsolę COMMAND, uruchom SOL, a następnie sprawdź listę procesów uruchomionych za pomocą polecenia TLIST -t. Oto próbka:
Explorer.exe (130)
ntvdm.exe (179) C:\command.corn
cmd.exe (168)
soi.exe (177) Solitaire
Należy zwrócić uwagę, że w 32-bitowym środowisku wirtualnego komputera Dosowego (NTVDM) pracuje 16-bitowa sesja interpretatora COMMAND, która uruchamia interpretator CMD, zawierający z kolei wątek (thread) Solitaire. Chociaż program TLIST pokazuje te procesy i procesy potomne, jeśli proces NTVDM zostanie usunięty (kill), to konsola CMD i jej wątek (thread) SOL zostaną.
Użytkownicy systemu Windows 9x, którzy przywykli do uruchamiania konsoli COMMAND za pomocą okna Run (Uruchom), powinni zamiast niej uruchomić CMD. Inter-pretator COMMAND.COM jest bardzo wolny w porównaniu z CMD. Nie powinno się uruchamiać konsoli COMMAND, o ile nie jest konieczny prawdziwy emulator DOS-a.
Nieobsługiwane wersje DOS-owe interpretatora poleceń COMMAND.COM
W przypadku komputera z systemem operacyjnym wybieranym przy starcie (dual-boot machinę), przy uruchamianiu konsoli C0MMAND.COM może pojawić się błąd. Dzieje się tak, ponieważ w ścieżce przeszukiwania znajduje się starsza wersja C0MMAND.COM. Należy usunąć lub zmienić nazwę starej wersji.
Rozszerzony został zbiór poleceń interpretatora CMD w stosunku do systemu DOS 6.2 i DOS-a w systemie Windows 9x. Interpretator CMD obsługuje język plików wsadowych (batch language) podobny do języka plików wsadowych (batch language) systemu DOS, ale bogatszy i mający możliwości wywoływania aplikacji 32-bitowych. Tworząc pliki wsadowe (batch files) w systemie Windows 2000, należy nadać im rozszerzenie CMD, aby zagwarantować, że zostaną uruchomione w środowisku 32-bitowym.
CMD rozpoznaje rozszerzenia z listy rozszerzeń nazw plików, więc wystarczy wpisać tylko nazwę pliku danych z odpowiednim rozszerzeniem, aby uruchomić związaną z nim aplikację. Na przykład zarejestrowanym rozszerzeniem konsoli MMC jest .msc. Po wpisaniu dnsmgmt.msc interpretator poleceń uruchomi
Interpretator CMD może być również podany w skrótach (shortcuts) uruchamiających aplikacje w trybie znakowym. Pozwala to wykorzystać zalety parametrów (switches) polecenia CMD, modyfikujących przebieg sesji. Oto lista parametrów (switches):
■ /C. Parametr ten zamyka okno sesji po zakończeniu działania aplikacji. Można na przykład użyć polecenia CMD /C do uruchomienia zdalnego klienta poczty (maił client), kiedy okno ma być zamknięte po zebraniu poczty i zakończeniu działania klienta.
■ /K. Parametr ten pozostawia okno sesji otwarte po zamknięciu aplikacji. Można na przykład użyć polecenia CMD /K w programie Scheduler (Zadania zaplanowane) aby uruchomić plik wsadowy wieczorem, a następnego dnia przeczytać komunikaty o błędach.
■ /D. Parametr ten blokuje funkcję AutoRun procesora CMD. Funkcja AutoRun umożliwia uruchamianie programu lub pliku wsadowego przy każdym otwarciu sesji konsoli. Funkcja ta nie jest normalnie aktywna. Można ją aktywować za pomocą następujących wartości w Rejestrze: HKLM\Software\Microsoft\Command Processor\AutoRun lub HKCU\Software\Microsoft\ Command Processor\AutoRun.
■ /V:ON. Parametr ten umożliwia opóźnione rozwinięcie (delayed expansion) zmiennej środowiska. W normalych warunkach zmienne środowiska są rozwijane (expanded), gdy tylko zostaną przetłumaczone (interpreted). W przypadku opóźnionego rozwinięcia (delayed expansion) zmiennej środowiska, zmienna ta nie jest rozwijana (expanded), dopóki polecenie nie zostanie wykonane. Zwykłe zmienne środowiska oznaczone są znakami %.... %. Opóźnione rozwinięcie (delayed expansion) zmiennej środowiska oznaczone jest wykrzyknikami !...!. Oto krótki przykład sposobu działania opóźnionego rozwinięcia (delayed expansion). Weźmy pod uwagę skrypt pod nazwą TEST. CMD, o następującej zawartości:
echo %username%
echo !username!
A oto przebieg wykonywania skryptu:
C:\>test
C:\>echo admin
admin
C:\>echo !username!
■ ...
kronos16