Projekt okładki i stron tytułowych Sebastian Rosik

Wydawca Łukasz Łopuszański

Redaktor prowadzący Jolanta Kowalczuk

Konsultacja i redakcja merytoryczna Mateusz Jurczyk

Redaktor Tomasz Łopuszański

Koordynator produkcji Anna Bączkowska

Przygotowanie publikacji elektronicznej Ewa Modlińska

Skład wersji elektronicznej na zlecenie Wydawnictwa Naukowego PWN Magdalena Wojtas / 88em.eu

Zastrzeżonych nazw firm i produktów użyto w książce wyłącznie w celu identyfikacji

Książka, którą nabyłeś, jest dziełem twórcy i wydawcy. Prosimy, abyś przestrzegał praw, jakie im przysługują. Jej zawartość możesz udostępnić nieodpłatnie osobom bliskim lub osobiście znanym. Ale nie publikuj jej w internecie. Jeśli cytujesz jej fragmenty, nie zmieniaj ich treści i koniecznie zaznacz, czyje to dzieło. A kopiując jej część, rób to jedynie na użytek osobisty.

Szanujmy cudzą własność i prawo

Więcej na www.legalnakultura.pl

Polska Izba Książki

Copyright © by Gynvael Coldwind

Warszawa 2015

eBook został przygotowany na podstawie wydania papierowego z 2015 r.

(wyd. I)

Warszawa 2015

ISBN 978-83-01-18460-5

Wydawnictwo Naukowe PWN SA

02-460 Warszawa, ul. Gottlieba Daimlera 2

tel. 22 69 54 321, faks 22 69 54 288

infolinia 801 33 33 88

e-mail: pwn@pwn.com.pl

www.pwn.pl

Przedmowa

Można śmiało powiedzieć, że na komputerach używanych w latach 70. i 80. ubiegłego wieku każdy dostępny fragment pamięci oraz cykl procesora był na wagę złota. W czasach, gdy masa megabajtu przestrzeni dyskowej była wyrażana w kilogramach, a programiści dysponowali niezwykle znikomą mocą obliczeniową, wyciskano siódme poty ze wszystkich instrukcji procesora, składających się na program, a o każdym bajcie było wiadomo, skąd się wziął i jaką rolę dokładnie odgrywa. Fakt ten był szczególnie widoczny na przykładzie starych gier wideo, które pomimo niewyobrażalnych dziś ograniczeń potrafiły zaskoczyć dopracowaniem oraz grywalnością na maszynach pokroju konsoli Atari 2600. Choć operowała ona na zaledwie 128 bajtach pamięci operacyjnej, to słynne produkcje, takie jak River Raid, Keystone Kapers czy Pitfall! na długo pozostały we wspomnieniach ówczesnych graczy. Z perspektywy lat trudno nie docenić kunsztu tych majstersztyków oraz umiejętności ich autorów.

Na skutek błyskawicznego rozwoju branży sprzętowej oraz powstawania coraz wygodniejszych systemów operacyjnych i środowisk programistycznych, szybszych i efektywniejszych kompilatorów czy w końcu samych języków programowania, lepiej skrojonych pod konkretne zastosowania i niezależnych od docelowej platformy, programowanie z biegiem czasu stało się w pewnym sensie łatwiejsze. Asembler został zamieniony na C, ten na C++, by następnie ustąpić w wielu przypadkach interpretowanym językom wysokiego poziomu, takim jak PHP, Java czy Python. Z drugiej strony postępujące oddalenie programisty od krzemu wykonującego tworzony kod utrudnia dostrzeżenie i zrozumienie pełnego obrazu tego, co dzieje się „pod maską” programu i całego środowiska uruchomieniowego. Na przykład wykonanie prostego skryptu „Hello, World!” napisanego w języku Python na systemie Windows składa się – w dużym uproszczeniu – z uruchomienia interpretera, przetłumaczenia kodu wysokiego poziomu na tzw. kod bajtowy (bytecode), obsłużenia każdej instrukcji tego kodu, przejścia do trybu jądra poprzez odpowiednie wywołanie systemowe, rasteryzacji tekstu do bitmapy i przesłania jej do sterownika graficznego, a w końcu na ekran. Ilu współczesnych programistów mogłoby opisać szczegółowo przebieg większości wymienionych etapów wykonania? Prawdopodobnie tylko nieznaczny procent – i choć nie jest to oczywiście problem sam w sobie, przykład ten ilustruje, jak długa jest lista zależności naszych aplikacji od elementów środowiska wykonawczego, z których istnienia możemy nawet nie zdawać sobie sprawy.

Mimo że zrozumienie wewnętrznych mechanizmów związanych z oprogramowaniem z całą pewnością przydaje się w pracy programisty, muszę przyznać, że główną motywacją wielu badań, które wspólnie z autorem tej książki przeprowadziliśmy podczas naszej 11-letniej znajomości, była zwyczajna ciekawość i rozrywka. Zagłębianie się w coraz to niższe partie środowiska wykonania aplikacji i skryptów, systemów operacyjnych czy w końcu samego procesora z czasem stało się swego rodzaju uzależnieniem pozwalającym na zaspokojenie głodu wiedzy. Szczególnie miło wspominam wczesne lata tego zauroczenia, gdy nierzadko w aktywnej jeszcze sieci IRC wystarczyło, by ktoś rzucił hasło: „Zróbmy konkurs na najmniejszy kompilator ezoterycznego języka Brainfuck!”, i już grupa ludzi rozmyślała przez tydzień nad ekstremalnymi optymalizacjami w asemblerze. Wkrótce potem zamiłowanie do niskopoziomowych aspektów informatyki i inżynierii wstecznej w naturalny sposób skierowała Gynvaela i mnie na tor bezpieczeństwa oprogramowania. Dalsze prace pozwoliły na odebranie prestiżowych nagród Pwnie Award (w tym wspólnej w 2013 r. w kategorii „Najbardziej Innowacyjne Badania Naukowe”), a stworzenie polskiej drużyny Dragon Sector na konkurowanie z najlepszymi zespołami Security CTF na świecie oraz zajęcie pierwszego miejsca w globalnym rankingu CTFtime.org w roku 2014.

Książka, którą trzymasz w ręku, jest wynikiem pasji, dociekliwości i wyjątkowego zacięcia dydaktycznego autora, które dotychczas ujawniało się w rozmaitych formach – od licznych, długich na kilka stron ekranowych postów na forach powiązanych z programowaniem i bezpieczeństwem, poprzez inicjatywę IRCowych wykładów (wyklady.net), posty na prywatnym blogu, wystąpienia na konferencjach i spotkaniach branżowych, aż po techniczne podcasty publikowane w serwisie YouTube. Dzieło to odbieram osobiście jako swoiste ukoronowanie edukacyjnej działalności autora. O prawdziwej wyjątkowości książki świadczy jednak przede wszystkim fakt, że podchodzi do tematyki inaczej niż podobne opracowania tego typu. Nie znajdziemy tutaj opisu składni lub wstępu do żadnego języka programowania, metodyk tworzenia oprogramowania czy wzorców architektonicznych – tematy te zostały już gruntownie opisane w innych publikacjach, a ich znalezienie nie stanowi problemu. W zamian autor, opierając się na swoim ponad 20-letnim doświadczeniu, skupił się na równie istotnych kwestiach, które bywają z reguły pomijane w innych źródłach, co skutkowało tym, że początkujący programiści byli zmuszeni dochodzić do nich sami na podstawie prób i błędów, tracąc przy tym energię i nabierając niekoniecznie prawidłowych nawyków lub przekonań.

Większość opisanych tutaj mechanizmów, technik i zachowań ma charakter ogólny i posiada zastosowanie niezależnie od użytego języka programowania, dotykając problemu tworzenia poprawnych i przemyślanych programów, a nie wyłącznie kompilującego się kodu. Część I porusza zagadnienia związane z codziennymi czynnościami programistycznymi, ze szczególnym uwzględnieniem konsoli i okna poleceń. Aspekt ten jest ważny głównie dla niedoświadczonych koderów, stawiających swoje pierwsze kroki w środowiskach konsolowych, choć często ignorowany lub traktowany po macoszemu. Część II opisuje najbardziej fundamentalne koncepty, kierujące współczesnym programowaniem, takie jak podstawy architektury komputerów, binarne kodowanie i operacje na typach liczb naturalnych, całkowitych i pseudorzeczywistych czy reprezentacja znaków i ich ciągów. Rozdziały te są jednymi z moich ulubionych, gdyż bardzo wyraźnie akcentują, jak pewne niskopoziomowe elementy środowiska wykonania przenikają i wpływają na kod wysokiego poziomu – za przykład mogą posłużyć niedokładne (wbrew intuicji) typy zmiennoprzecinkowe w językach takich jak Java czy Python, czy niekompatybilność reprezentacji ciągów tekstowych używanych wewnętrznie i przekazywanych do funkcji biblioteki standardowej, umożliwiająca atak typu poison null byte w starszych wersjach PHP. Części III, IV i V omawiają najważniejsze komponenty środowiska uruchomieniowego aplikacji, wprowadzając Czytelnika w świat procesów i wątków (jak również związanych z nimi problemów), interakcji z systemem plików oraz samymi plikami, a także komunikacji pomiędzy programami. Wszystkie rozdziały są okraszone olbrzymią dawką technicznych smaczków, studiów przypadku i przykładowych listingów kodu, tworząc lekturę wypełnioną po brzegi treścią.

Z pełnym przekonaniem polecam ten tytuł każdemu początkującemu i średnio zaawansowanemu programiście, a przede wszystkim tym, którzy zamiast pobieżnych wyjaśnień dostępnych w wielu opracowaniach (np. „zmienna typu short może przechowywać wartości z zakresu od –32768 do 32767”) wolą poznać pełną historię. Uważam, że jest to pozycja obowiązkowa na półce każdego zainteresowanego tą dziedziną informatyki, tuż obok książki do nauki konkretnego języka programowania oraz podręcznika do algorytmów i struktur danych; idealnie wypełni ona lukę dotyczącą podstaw środowiska wykonawczego oraz kluczowych mechanizmów używanych w oprogramowaniu w praktycznych zastosowaniach. Życzę Ci, Czytelniku, dobrej zabawy na kolejnych kartach tego tomu, gdyż to właśnie zabawa i fascynacja tematem pomagają z łatwością Zrozumieć programowanie.

Mateusz Jurczyk

Senior Software Engineer, Google

Kraków, wrzesień 2015 r.

Wstęp

O autorze, o książce

Kiedy miałem siedem lat, zostałem dumnym posiadaczem swojego pierwszego, własnego komputera Atari 800XL wraz z magnetofonem oraz dwoma dżojstikami; do zestawu był również dołączony zestaw kaset z przeróżnymi grami, takimi jak River Ride, Bruce Lee czy Archon. Wczytanie gry trwało zazwyczaj od pięciu do dziesięciu minut, a więc całą wieczność dla niecierpliwego dziecka. Na szczęście jedna z gier nie wymagała kasety i była dostępna od razu po włączeniu komputera – nazywała się Atari BASIC i była grą w programowanie. Co więcej, była do niej dołączona instrukcja w formie zdobytej cudem kserokopii książki, która dla osoby rozpoznającej litery, ale niekoniecznie umiejącej złożyć je w wyrazy, stanowiła zagadkę, tak samo jak BASIC. Niemniej jednak umiejętność czytania nie jest potrzebna, by przepisywać kolejne znaki z przykładowych listingów, co też z upodobaniem czyniłem – najpierw z kserówek, a potem z kolejnych numerów czasopisma „Bajtek”, po które co miesiąc udawałem się wraz z którymś z rodziców do pobliskiego kiosku.

Na samym przepisywaniu listingów się nie kończyło – jeszcze większą radość przynosiło mi nanoszenie rozmaitych zmian we wprowadzonych programach i obserwowanie ich skutków. W efekcie okazało się, że parametry rozkazu REM były bez znaczenia (z czym wiązała się inna świetna wiadomość – nie trzeba było ich przepisywać!), parametry komendy PRINT były wypisywane na ekran, po instrukcji GOSUB musiało znaleźć się RETURN, a GRAPHICS na spółkę z PLOT i DRAWTO pozwalały rysować kolorowe linie. Z każdym przepisanym listingiem poznawałem coraz więcej wzorców, a z każdą wprowadzoną zmianą coraz lepiej rozumiałem to, co właściwie działo się w programie.

Bardzo szybko zacząłem również pisać własne, proste programiki, które z biegiem czasu stawały się coraz dłuższe i bardziej złożone. Wkrótce potem w domowym salonie stanął komputer kompatybilny z IBM PC, wyposażony w procesor 80286, 1 MB RAM, stację dyskietek 5,25" i kartę graficzną Hercules oferującą jedynie monochromatyczne tryby graficzne i tekstowe. Wraz z nim nadszedł czas nauki nowego wariantu znanego mi już języka – stworzonego przez Microsoft GW-BASIC. Wkrótce potem komputer został doposażony w dysk twardy o pojemności 50 MB, co umożliwiło zainstalowanie pełnego systemu MS-DOS 5 wraz z interpreterem języka QBasic, a później także Windows 3.1 i potężnym IDE języka Visual Basic 1.0. Czas leciał, leciwy 80286 został wymieniony na wielokrotnie szybszy 80486, a z języka Visual Basic przeniosłem się na Turbo Pascal. W kolejnych latach pojawiły się procesory z rodziny Pentium, pierwsze akceleratory 3D do kart graficznych (wtedy jeszcze jako osobne urządzenia), a także ogólnodostępny Internet za sprawą numeru 0–20 21 22. Wraz z nim uzyskałem dostęp do sieci IRC, grup dyskusyjnych i hobbystycznie prowadzonych stron internetowych poświęconych różnym językom programowania. Tymczasem trafiłem do liceum, komputer przeszedł kolejną metamorfozę i został wyposażony w procesor Intel Celeron taktowany z częstotliwością 333 MHz oraz kartę graficzną z wbudowaną akceleracją 3D, a ja za namową znajomego porzuciłem Turbo Pascal na rzecz C++ i OpenGL; moje zainteresowanie wzbudził też temat inżynierii wstecznej. Potem nadeszły studia na Politechnice Wrocławskiej, kolejne języki programowania w niemałej liczbie i coraz bardziej skomplikowane projekty. Na drugim roku rozpocząłem pierwszą pracę jako programista i reverse engineer dla jednej z polskich firm antywirusowych, coraz bardziej interesując się również zagadnieniami związanymi z bezpieczeństwem komputerowym. Wkrótce przeszedłem do hiszpańskiej firmy Hispasec, skończyłem studia inżynierskie, by ostatecznie trafić do firmy Google, w której pracuję do dzisiaj.

Spoglądając w przeszłość, mogę powiedzieć, że moja fascynacja wszystkim, co wiąże się z komputerami, a w szczególności programowaniem, nigdy nie minęła, mimo że zaczęła się ponad ćwierć wieku temu – jednym z jej efektów było napisanie książki, którą właśnie, Czytelniku, trzymasz w ręku. Podczas jej tworzenia starałem się uchwycić preferowane przeze mnie podejście do programowania, które jest zabarwione ciekawością, chęcią zrozumienia tego, jak każdy z używanych mechanizmów działa od środka, a także zamiłowaniem do niskopoziomowych zakątków informatyki. Co za tym idzie, książkę pisałem z myślą o pasjonatach, dla których programowanie jest jednocześnie wyzwaniem i świetną zabawą, bez względu na to, czy programują jedynie dla przyjemności, czy też pracują w zawodzie.

Dobierając zawartość książki, starałem się przede wszystkim wybrać tematy, o które często pytają początkujący i średnio zaawansowani programiści – stąd m.in. obecność rozdziałów o wątkach, gniazdach sieciowych czy plikach binarnych. Do spisu treści trafiły również tematy moim zdaniem istotne dla każdego programisty, takie jak niskopoziomowe kodowanie danych, synchronizacja procesów wielowątkowych czy choćby korzystanie z wiersza poleceń. Chciałem jednak również wskazać, że programowanie nie kończy się na aplikacjach narzędziowych lub „usługowych”, stąd obecność ostatniego rozdziału książki zatytułowanego „Programowanie dla zabawy”. Jednocześnie zdecydowałem się pominąć pewne, skądinąd bardzo istotne, zagadnienia, takie jak algorytmy, wzorce projektowe czy szczegółowe opisy konkretnych języków programowania – są one opisane w wielu innych, bardziej wyspecjalizowanych publikacjach.

Przykłady w książce zostały napisane w różnych językach programowania – są to przede wszystkim Python, C, C++ oraz Java. Ta nietypowa różnorodność brała się z chęci podkreślenia, że w większości środowisk występują te same podstawowe mechanizmy, których używa się w bardzo podobny sposób niezależnie od wybranego języka programowania, a różnice często sprowadzają się wyłącznie do nazw bibliotek, funkcji, klas itp. Jednocześnie z uwagi na specyfikę poszczególnych języków oraz ich umowną klasyfikację jako nisko- bądź wysokopoziomowe istnieją zadania łatwiejsze i trudniejsze do wykonania w każdym z nich – na przykład korzystanie z zaawansowanych funkcji oferowanych przez system operacyjny jest łatwiejsze w C i C++, ale już przetwarzanie danych tekstowych jest zdecydowanie prostsze w językach pokroju Python. Ostatecznie nie ma języka idealnego – warto więc, by programista znał ich kilka i zgodnie z zasadą use the right tool for the right job oraz własnymi preferencjami wybierał język adekwatny do danego zadania. Tak jak nie istnieje idealny język programowania, tak nie ma również idealnego systemu operacyjnego, stąd tematy poruszane w książce omawiam w kontekście dwóch popularnych rodzin systemów: Microsoft Windows oraz GNU/Linux (w szczególności Ubuntu).

Kontynuując temat przykładowych programów, starałem się również, by listingi miały wewnętrznie spójny styl, ale jednak zróżnicowany pomiędzy sobą – jednym z celów książki było zaprezentowanie fragmentów istniejącego ekosystemu programistycznego, w którym różni programiści stosują odmienne style tworzenia kodu. Warto więc jak najwcześniej nabrać pewnej elastyczności w tej kwestii – choć każdy projekt powinien konsekwentnie kierować się zasadami konkretnego stylu, jego wybór jest często kwestią osobistych preferencji programisty.

Nie w każdym przykładowym kodzie zawarłem pełne sprawdzanie błędów – wynikało to z chęci zwiększenia czytelności listingów i redukcji ich długości, która w przeciwnym razie mogłaby być przytłaczająca dla bardziej początkujących Czytelników. W przypadku rozwijania kodu produkcyjnego (tj. o wysokiej jakości) pełne sprawdzanie błędów jest w zasadzie obowiązkowe, choć oczywiście nie każdy tworzony kod musi przystawać do takich standardów. W trakcie pracy nad pomocniczymi narzędziami jednorazowego użytku czy rozwiązaniami zadań podczas konkursów trwających kilka lub kilkadziesiąt godzin obranie drogi „na skróty” może nierzadko zaoszczędzić sporo czasu i okazać się ostatecznie strategią najkorzystniejszą.

W książce oprócz przykładowych listingów kodu występuje również znaczna liczba ramek oznaczonych jako [VERBOSE] oraz [BEYOND]. Celem tych pierwszych jest dokładniejsze przedyskutowanie zagadnień, które pojawiają się w tekście, i są skierowane przede wszystkim do bardziej początkujących Czytelników. Zawartość ramek [BEYOND] natomiast znacznie rozwija tematykę i często wykracza poza średni poziom skomplikowania danego rozdziału – jestem przekonany, że nawet zaawansowani programiści mogą w nich znaleźć coś nowego i ciekawego.

Chciałbym również zachęcić do odwiedzenia oficjalnego serwisu „Zrozumieć Programowanie”, w którym można znaleźć przykładowe kody źródłowe, erratę, jak i niewielkie forum stworzone z myślą o dyskusji na tematy poruszane w książce, w tym również o ćwiczeniach i flagach. Znajduje się on pod adresem:

http://gynvael.coldwind.pl/book/

Podziękowania

W powstaniu i nadaniu ostatecznego kształtu tej książce swój udział miało wiele osób, którym chciałbym w tym miejscu podziękować. Mojej żonie Arashi Coldwind za wsparcie okazywane podczas całego czasu trwania tego, bądź co bądź, niemałego projektu, jakim jest napisanie książki. Autorowi przedmowy, a jednocześnie redaktorowi merytorycznemu i mojemu dobremu przyjacielowi Mateuszowi Jurczykowi, który na edycję i korektę tej książki poświęcił ogromną ilość własnego czasu. Tomaszowi Łopuszańskiemu, który wraz ze mną przesiadywał do późnych godzin nocnych, przeglądając i szlifując każdy kolejny nadesłany rozdział. Łukaszowi Łopuszańskiemu, który przekonał mnie do napisania tej książki i doprowadził do jej wydania. Sebastianowi Rosikowi za genialny projekt okładki. Recenzentom merytorycznym, którzy wychwycili znaczą liczbę niedociągnięć obecnych w pierwotnej wersji, a byli to: Paweł „KrzaQ” Zakrzewski, Robert „Jagger” Święcki, Mariusz Zaborski, Unavowed, Michał Leszczyński, Michał Melewski, Karol Kuczmarski, Adam „pi3” Zabrocki, Sergiusz „q3k” Bazański, Tomasz ‚KeiDii’ Bukowski. Testerom, którzy wskazali dodatkowe błędy i nieścisłości, w składzie: Łukasz „Stiltskin” Głowacki, Nism0, Łukasz „Lord Darkstorm”, Trzeciakiewicz, Alan Cesarski. A także Ange Albertiniemu, Mikołajowi Koprasowi, Mattowi Moore’owi, Ferminowi Sernie oraz Michałowi Zalewskiemu.

Mam nadzieję, Drogi Czytelniku, że książka ta będzie dla Ciebie ciekawą i inspirującą lekturą.

Gynvael Coldwind

Zurych, wrzesień 2015 r.

Zgłaszanie błędów i errata

W idealnym wszechświecie napisałbym książkę bez błędów, w której nie byłoby miejsca na literówki czy brakujące przecinki. Niestety, książka ta pochodzi z naszego wszechświata, więc wbrew wszelkim staraniom błędy na pewno się pojawią.

Z tego względu chciałbym zachęcić Czytelników do zaglądania od czasu do czasu na stronę z erratą, którą będę aktualizował przy okazji każdego znalezionego lub zgłoszonego błędu merytorycznego. Erratę można znaleźć pod adresem:

http://gynvael.coldwind.pl/book/errata

Chciałbym również zachęcić Czytelników do zgłaszania wszelkiego rodzaju błędów, zarówno merytorycznych, jak i językowych – wszystkie zauważone niedociągnięcia będą eliminowane w kolejnych wydaniach książki. Informacje na temat wykrytych błędów proszę zgłaszać pod poniższym adresem:

http://gynvael.coldwind.pl/book/bugbounty

Dodatkowo, naśladując niejako Donalda Knutha[1], postaram się wysłać pamiątkową pocztówkę każdemu Czytelnikowi, który jako pierwszy zgłosi dany błąd merytoryczny. Szczegóły tego swoistego bug bounty można również znaleźć na wspomnianej stronie internetowej.

Część I
Kilka codziennych czynności

Ryzykując otarcie się o banał, napiszę, że w skład umiejętności niezbędnych programiście wchodzą:

Umiejętność projektowania architektury programów, funkcji, klas, protokołów itp.

Znajomość algorytmów, struktur danych i wzorców projektowych.

Znajomość przynajmniej jednego języka programowania i sprawność w posługiwaniu się nim.

Umiejętność, którą osobiście określam mianem „tłumaczenia myśli na kod”.

Jak się często okazuje, umiejętności te są konieczne, ale nie zawsze wystarczające, aby biegle tworzyć i analizować oprogramowanie. Wynika to z dwóch faktów: programy ani nie działają w próżni, ani nie są tworzone w jednolity sposób przez niewielką grupę osób. Oznacza to, że programista musi zapoznać się również z ekosystemem, w którym są tworzone i wykonywane jego programy, oraz pogodzić się z myślą, że inni programiści tworzą kod w odmiennych językach bądź na podstawie innych zasad (lub ich braku).

W niniejszym rozdziale chciałbym wskazać i opisać kilka codziennych czynności, które „przytrafiają się” programistom. Dodam, że niektóre z nich mogą być konieczne do zrozumienia i prawidłowej interpretacji pewnych fragmentów książki; w szczególności chciałbym zachęcić do zapoznania się z rozdziałami: „Konsola i interpreter poleceń” – to właśnie konsolę wykorzystuję w zdecydowanej większości przykładów w niniejszej książce, oraz „Czytanie nieznanego języka”, ponieważ przykładowe listingi zostały sporządzone w różnych językach, a często również w odmiennych stylach tworzenia kodu[2].

Rozdział 1
Konsola i interpreter poleceń

Pomimo upływu lat konsola nadal jest jednym z podstawowych narzędzi wykorzystywanych przez zaawansowanych programistów i administratorów systemów – w praktyce konsola i interpreter poleceń to często niezwykle wygodne i przydatne narzędzia, a w niektórych wypadkach stanowią wręcz jedyną możliwość skorzystania z pewnych programów. Zarówno konsola, jak i interpreter to de facto standard w przypadku większości unixowych systemów operacyjnych (rys. 1).

Rysunek 1. ConEmu-Maximus[3], DOSBox[4] z uruchomioną aplikacją w trybie tekstowym oraz GNOME Terminal[5]

Na samym początku warto wyjaśnić pewną nieścisłość związaną z używanymi terminami, a mianowicie: czym jest konsola, a czym interpreter poleceń?

Konsola (nazywana również emulatorem terminalu lub potocznie – terminalem) jest pewnego rodzaju środowiskiem wykonania, z którego mogą (ale nie muszą) korzystać aplikacje – należy od razu zaznaczyć, że w danym momencie z jednej konsoli może korzystać wiele aplikacji. Elementem centralnym jest bufor tekstowy o określonej (ale niekoniecznie stałej) wielkości, który jest w całości lub częściowo wyświetlany w oknie konsoli i który może być pośrednio lub bezpośrednio modyfikowany przez wszystkie aplikacje z niej korzystające. Dodatkowo w danym momencie jedna aplikacja jest tzw. aplikacją pierwszoplanową (foreground) – wejście z klawiatury, a czasem również myszki, jest przekazywane właśnie do niej.

Domyślnie dane wypisywane przez aplikację na standardowe wyjście (stdout) oraz standardowe wyjście błędów (stderr) są również odbierane przez konsolę, która wyświetla tekst, biorąc pod uwagę wszystkie znaki specjalne i sekwencje kontrolne oraz pozycję kursora. Analogicznie wejście z klawiatury jest przesyłane przez konsolę na standardowe wejście (stdin) aplikacji pierwszoplanowej[6].

Z punktu widzenia użytkownika konsola jest po prostu tekstowym interfejsem wykorzystywanym przez niektóre programy. Jedną z podstawowych aplikacji korzystających z konsoli jest właśnie interpreter poleceń (command processor lub command-line interpreter), nazywany czasem powłoką systemową (shell)[7], który zwyczajowo udostępnia użytkownikowi zestaw poleceń i funkcji do:

Nawigacji w systemie (polecenia typu cd, dir lub ls, pwd itp.).

Konfigurowania środowiska uruchomieniowego, w tym zmiennych środowiskowych (set, export, path, ulimit itp.).

Uruchamiania innych programów z podanymi argumentami i ewentualnymi przekierowaniami strumieni stdin/stdout/stderr.

Tworzenia skryptów automatyzujących powyższe czynności.

Przykładowe interpretery poleceń to m.in.:

cmd.exe (Windows);

PowerShell (Windows);

Bash (GNU/Linux itp.);

Z shell (GNU/Linux itp.).

W dalszych podrozdziałach opiszę główne koncepty (przekierowania, argumenty, zmienne środowiskowe, katalog roboczy) wykorzystywane przy pracy z interpreterami poleceń, przy czym skupię się na dwóch z nich: cmd.exe (Windows 7) oraz Bash (Ubuntu 14.04.2 LTS). Ponieważ będzie to opis skrócony, zachęcam czytelników do bliższego przyjrzenia się wybranemu przez siebie interpreterowi we własnym zakresie. Pominę również opis większości poleceń (zarówno wbudowanych, jak i dostępnych w systemie operacyjnym) do operacji na plikach i katalogach – zostały one opisane w wielu innych, łatwo dostępnych publikacjach, np.:

Bash:

– http://www.tldp.org/LDP/GNU-Linux-Tools-Summary/html/c2690.htm

– http://www.tldp.org/LDP/GNU-Linux-Tools-Summary/html/x3289.htm

cmd.exe:

– http://en.wikibooks.org/wiki/Guide_to_Windows_Commands/File_and_Directory_Management

– http://en.wikibooks.org/wiki/Guide_to_Windows_Commands/File_Commands

1.1. Wykorzystanie interpretera

Poniżej zaprezentowalem kilka przykładów użycia interpretera wraz z krótkim, wysokopoziomowym opisem ich działania. Większość użytych mechanizmów jest wyjaśniona w dalszej części tego rozdziału.

(Ubuntu) reset && make test

(Windows) cls && make test

Wyczyszczenie okna konsoli oraz rekompilacja projektu i jego uruchomienie (przy wykorzystaniu skryptu Makefile). W przypadku dystrybucji Ubuntu osobiście preferuję stosowanie komendy (programu) reset zamiast clear, ponieważ w emulatorze konsoli, z którego korzystam (GNOME Terminal), reset czyści cały bufor tekstowy konsoli, natomiast clear jedynie przewija ekran niżej tak, by wydawało się, że został on wyczyszczony – jest to istotne, gdy kompilacja lub uruchomienie projektu powoduje wypisanie dużej ilości tekstu, a dla nas wygodne byłoby szybkie przewinięcie ekranu na początek danych. Alternatywnie można by skorzystać np. z polecenia make test 2>&1 | less.

(Ubuntu) python gen_input.py | LD_PRELOAD=`pwd`/debug.so ./app

Uruchomienie skryptu gen_input.py, który generuje na standardowe wyjście pewne dane wejściowe dla aplikacji app – są one przekazywane na jej standardowe wejście. Dodatkowo niektóre importowane przez aplikację funkcje zostaną podmienione na funkcje o tej samej nazwie, znajdujące się w dynamicznej bibliotece debug.so, która umieszczona jest w obecnym katalogu roboczym.

(Ubuntu) for i in {1..1000}; do ./a.out $i; cp out.data data/$i.data; done

(Windows) for /l %i in (1,1,1000) do @(a.exe %i && copy out.data data\%i.data)

Uruchomienie aplikacji a.out / a.exe tysiąc razy z kolejnymi liczbami (od 1 do 1000) w pierwszym parametrze. Za każdym razem wygenerowany przez aplikację plik out.data jest kopiowany do katalogu data i nadawana jest mu nowa nazwa w formacie <liczba z argumentu>.data.

(Ubuntu) watch pep8 test.py

Co dwie sekundy (domyślne opóźnienie programu watch) okno konsoli jest czyszczone, a następnie uruchomiony zostaje walidator stylu PEP 8 języka Python. Jest to wygodne rozwiązanie, jeśli w tym czasie w osobnym oknie poprawiamy skrypt test.py i chcemy od razu widzieć, czy zmiany odniosły zamierzony skutek (tj. czy ostrzeżenie o nieprawidłowym stylu zniknęło).

Kilka innych przykładów pojawia się również w innych miejscach w tym rozdziale.

1.2. Przekierowania

Jedną z najważniejszych cech interpreterów jest możliwość przekierowania standardowego wyjścia (oznaczanego najczęściej deskryptorem 1), wyjścia błędów (2) i wejścia (0) procesów oraz łączenia ich między procesami. Najłatwiej jest to wytłumaczyć na przykładach (które są poprawne zarówno dla Bash, jak i cmd.exe; prawdopodobnie zadziałają również w przypadku większości innych współczesnych interpreterów):

program > xyz

Wszystkie dane wypisywane na standardowe wyjście przez uruchomiony program trafią do pliku xyz (jeśli plik ten istnieje, zostanie nadpisany). Jest to idealne rozwiązanie, gdy danych jest dużo, a my chcemy je na spokojnie przejrzeć lub użyć jako danych wyjściowych w późniejszym terminie.

Alternatywnie można by napisać program 1>xyz, choć nie jest to konieczne, ponieważ standardowe wyjście (1) jest domyślnym argumentem dla przekierowania w tę stronę.

program 2> errors

Podobnie jak wyżej, z tą różnicą, że do pliku errors trafią dane wypisywane na standardowe wyjście błędów.

program >> xyz

Analogicznie jak w powyższych przypadkach, przy czym dane (ze standardowego wyjścia) zostaną dopisane na koniec pliku xyz.

program < input

Program otrzyma dane z pliku input na standardowe wejście (tj. czytanie ze standardowego wejścia będzie równoznaczne z czytaniem z pliku input). To przekierowanie idealnie nadaje się do powtarzanych wielokrotnie testów aplikacji odczytujących dane ze standardowego wejścia – dzięki temu nie trzeba ich za każdym razem wprowadzać ręcznie.

program 2>&1

Przekierowanie standardowego wyjścia błędów na standardowe wyjścia; przydatne rozwiązanie, jeśli zachodzi potrzeba przefiltrowania standardowego wyjście błędów (patrz dalej).

program >xyz 2>&1

Przekierowanie obu standardowych wyjść do pliku xyz. Mogłoby się wydawać, że warianty program 2>&1 >xyz lub program >xyz 2>xyz również zadziałają, jednak tak niestety nie jest (patrz również ramka „Jak rozwiązywane są przekierowania [VERBOSE]” oraz ramka „Dwa przekierowania do jednego pliku [BEYOND]”).

program | inny_program

Standardowe wyjście pierwszego programu zostanie przekierowane na standardowe wejście drugiego programu. Drugi program najczęściej albo filtruje otrzymane dane (np. wyszukując tylko podanych wzorców), albo poddaje je dalszej obróbce.

Jak rozwiązywane są przekierowania [VERBOSE]

Wspomniałem już, że przy przekierowaniu obu standardowych wyjść (stdout, stderr) do jednego pliku należy użyć polecenia program >xyz 2>&1 oraz że podanie przekierowań w odwrotnej kolejności nie zadziała zgodnie z oczekiwaniami – wynika to ze sposobu ich realizacji.

W dużym uproszczeniu: o stosowanym zapisie w stylu lewa_strona>prawa_strona, lewa_strona<prawa_strona itd. można myśleć jako o standardowej operacji przypisania lewa_strona = prawa_strona, przy założeniu, że obie strony są zmiennymi (deskryptorami), które w tym przypadku reprezentują faktyczne odwołania do potoków, plików, konsoli itp.

Warto pamiętać, że punktem wyjścia są zawsze deskryptory stdin/stdout/stderr odziedziczone po procesie interpretera (rodzica), a więc:

deskryptor 0 (w przykładzie poniżej oznaczany jako fd0), czyli stdin procesu potomnego, wskazuje na to samo urządzenie standardowego wejścia, które jest używane przez interpreter;

deskryptor 1 (fd1), czyli stdout procesu potomnego, wskazuje na stdout procesu rodzica;

deskryptor 2 (fd2), czyli stderr procesu potomnego, wskazuje na stderr procesu rodzica.

Korzystając z powyższego uproszczenia i mając na uwadze punkt wyjścia, rozważmy, co się stanie w przypadku wykonania polecenia program 2>&1 >xyz:

1. 2>&1 (a więc fd2=fd1) – deskryptor 2 ma od teraz wskazywać na ten sam potok/plik itp., do którego odnosi się deskryptor 1. W tym momencie deskryptor 1 wskazuje na odziedziczone po interpreterze stdout, zatem deskryptor 2 od tego momentu będzie również odnosić się do standardowego wyjścia interpretera.

2. >xyz (a więc fd1=file("xyz", WRITE)) – deskryptor 1 od teraz ma wskazywać na nowo otwarty (do zapisu) plik xyz. Deskryptor 2 nie jest w żaden sposób uaktualniany ani zmieniany, zatem cały czas odnosi się do standardowego wyjścia interpretera.

Podsumowując, w momencie faktycznego uruchomienia programu (przekierowania odbywają się bezpośrednio przed jego uruchomieniem), stdout nowego procesu (deskryptor 1) jest przekierowane do pliku xyz, a stderr (deskryptor 2) wskazuje na stdout procesu rodzica (interpretera). Nic natomiast nie zmieniło się w przypadku stdin (deskryptor 0).

Rozważmy jeszcze jeden przypadek. Załóżmy, że chcemy zamienić stdout i stderr miejscami, tak aby stdout uruchamianego procesu wskazywało na stderr interpretera, oraz analogicznie, aby stderr uruchamianego procesu wskazywało na stdout interpretera. W tym celu należy stworzyć dodatkowy tymczasowy deskryptor (podobnie jak przy zamianie miejscami wartości zmiennych) i z niego skorzystać.

Polecenie, którego użyjemy, wygląda następująco: program 3>&1 1>&2 2>&3. Rozważmy, co się dzieje w kolejnych krokach przekierowań:

1. 3>&1 (a więc fd3=fd1) – ma zostać utworzony nowy deskryptor – 3 (fd3), który ma wskazywać na to samo, co deskryptor 1, czyli na odziedziczone po interpreterze stdout.

2. 1>&2 (a więc fd1=fd2) – od teraz deskryptor 1 ma wskazywać na to samo, co deskryptor 2, czyli na odziedziczone po interpreterze stderr.

3. 2>&3 (a więc fd2=fd3) – od teraz deskryptor 2 ma wskazywać na to samo, co deskryptor 3, czyli na odziedziczony po interpreterze stdout.

Ostatecznie w momencie uruchomienia programu stdout nowego procesu będzie wskazywać na stderr procesu interpretera, a stderr nowego procesu na stdout interpretera.

Aby przetestować opisany mechanizm w praktyce, warto stworzyć pomocniczy program, np. w języku Python (2.7):

import sys

print>>sys.stderr, "STDERR"

print "STDOUT"

Przetestowanie podmiany będzie wymagało od nas upewnienia się, że stdout i stderr interpretera wskazują na różne urządzenia. Możemy np. wywołać interpreter z przekierowanymi stdout/stderr do oddzielnych plików oraz nakazać mu uruchomić pomocniczy program ze wspomnianymi przekierowaniami:

Ubuntu:

$ bash -c -- "python p1.py 3>&1 1>&2 2>&3" >log_stdout 2>log_stderr

$ cat log_stdout

STDERR

$ cat log_stderr

STDOUT

Windows:

> cmd /c "python p.py 3>&1 1>&2 2>&3" >log_stdout 2>log_stderr

> type log_stdout

STDERR

> type log_stderr

STDOUT

Więcej informacji na temat przekierowań można znaleźć w oficjalnym podręczniku Basha [1] oraz na MSDN [2].

Dwa przekierowania do jednego pliku [BEYOND]

Wspomniałem również o drugim intuicyjnym, lecz błędnym sposobie przekierowania obu standardowych wyjść do jednego pliku: program >xyz 2>xyz. Dlaczego wariant ten jest niepoprawny?

Na systemach z rodziny Windows odpowiedź otrzymujemy natychmiast:

> program >xyz 2>xyz

The process cannot access the file because it is being used by another process.

Interpreter zgłosił, że plik xyz jest już otwarty przez inny proces, nie można go więc użyć do przekierowania. „Innym procesem” w tym przypadku jest sam interpreter, który przy realizacji wyrażenia >xyz sam otworzył wskazany plik, ustawiając flagę FILE_SHARE_READ, która zezwala na ponowne otwarcie tego pliku jedynie do odczytu. Przy realizacji 2>xyz interpreter próbuje ponownie otworzyć plik xyz do zapisu, co skutkuje błędem ze względu na wspomnianą flagę.

W przypadku interpretera Bash polecenie wykona się, lecz w pliku xyz znajdziemy jedynie strzępy informacji. Wynika to z faktu, że obie próby otwarcia pliku xyz powiodły się. Są one jednak przypisane do oddzielnych deskryptorów, co łatwo sprawdzić, korzystając z programu strace:

> strace -f bash -c -- "program >xyz 2>xyz" 2>&1 | grep -A 3 'open("xyz'

[pid 7716] open("xyz", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3

[pid 7716] dup2(3, 1) = 1

[pid 7716] close(3) = 0

[pid 7716] open("xyz", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3

[pid 7716] dup2(3, 2) = 2

[pid 7716] close(3) = 0

[pid 7716] execve("/program", ["program"], [/* 22 vars */]) = 0

Ponieważ każdy deskryptor ma swój własny, niezależny kursor zapisu (patrz również część IV książki), który najpierw jest ustawiony na początek pliku, to przy każdej operacji zapisu mogą zostać nadpisane dane, które zostały zapisane, korzystając z drugiego deskryptora. Można to przetestować, używając pomocniczego skryptu (Python 2.7):

import sys

sys.stdout.write("aaaaaa")

sys.stdout.flush()

sys.stderr.write("AAA")

Zaprezentowany program (w kontekście omawianego przekierowania) zapisuje do pliku ciąg "aaaaaa", korzystając z deskryptora stdout – jego kursor zapisu jest zatem przesunięty o 6 bajtów do przodu, dzięki czemu następny zapis korzystający z tego deskryptora wyemituje dane za już istniejącymi. Dwie linie dalej zapisanie ciągu "AAA" używa innego deskryptora, wskazującego na ten sam plik – stderr. Kursor zapisu tego deskryptora cały czas wskazuje na początek pliku, a więc tam właśnie trafią dane. W efekcie powinniśmy otrzymać ciąg "AAAaaa", co możemy sprawdzić, uruchamiając skrypt z przekierowaniami:

$ python test.py >xyz 2>xyz

$ cat xyz

AAAaaa

Podsumowując, opisana metoda przekierowania nie pozwala na skuteczne zapisanie wszystkich danych wypisywanych na stdout i stderr.

1.3. Przykładowe polecenia wykorzystujące przekierowania

Poniżej zaprezentowałem kilka typowych przykładów wykorzystania przekierowań wraz z ich wyjaśnieniem:

(Ubuntu) program | less

(Windows) program | more

Wyświetl dane ze standardowego wyjścia programu po jednej stronie ekranowej naraz.

(Ubuntu) ps aux | grep "python"

(Windows) tasklist | find "python"

Przefiltruj standardowe wyjście poleceń ps aux i tasklist w poszukiwaniu słowa „python”. W praktyce wypisane zostaną przede wszystkim informacje o procesach Pythona.

(Ubuntu) strace -e trace=file program 2>&1 | grep passwd

Przefiltruj logi generowane przez strace w poszukiwaniu słowa „passwd”. W praktyce wypisane zostaną przede wszystkim bezpośrednie interakcje procesu z plikiem passwd.

(Ubuntu) cat /etc/passwd | wc -l

Wypisz, ile linii ma plik /etc/passwd. Pod Windowsem analogiczny efekt można uzyskać jedynie niebezpośrednio (np. korzystając z polecenia find /c /v "ciąg", aby wypisać liczbę linii niezawierających danego ciągu, który należy dobrać tak, by nigdy nie wystąpił w pliku), ale w praktyce lepiej jest zainstalować np. pakiet GnuWin32 [3] i skorzystać z wc -l.

(Ubuntu) program | grep -i "warning" | sort > warning.log

(Windows) program | find /i "warning" | sort > warning.log

Uruchom program, przefiltruj jego wejście pod kątem linii zawierających słowo „warning” (wielkość liter nie ma znaczenia), a następnie posortuj linie alfabetycznie i zapisz je do pliku warning.log.

1.4. Bieżący katalog roboczy

W skład środowiska, w którym działa aplikacja, wchodzi tzw. katalog roboczy (nazywany czasem w skrócie cwd lub rzadziej – wd), czyli po prostu jeden z katalogów w systemie plików, w którym dana aplikacja została uruchomiona lub który dana aplikacja wybrała po uruchomieniu. Katalog roboczy jest wykorzystywany przez system operacyjny jako domyślny katalog w przypadku operacji na systemie plików korzystających ze ścieżek względnych (tj. relatywnych względem katalogu roboczego). Należy dodać, że operując na ścieżkach (dotyczy to zarówno interpretera, większości innych aplikacji, jak i większości poleceń w językach programowania), można użyć dodatkowo dwóch pseudokatalogów:

. (kropka) – obecny katalog;

.. (dwie kropki) – nadrzędny katalog.

Ponadto niektóre interpretery poleceń udostępniają pseudokatalog ~ (tylda) oznaczający katalog domowy użytkownika (zazwyczaj /home/<nazwa użytkownika> w przypadku systemów unixowych).

Interpreter poleceń posiada zazwyczaj szereg poleceń do zmiany oraz wyświetlenia katalogu roboczego (tab. 1), np.:

Tabela 1. Przykładowe polecenia operujące na katalogu roboczym

Bash

cmd.exe

Opis

pwd

cd

Wyświetlenie obecnego katalogu roboczego.

cd xyz

cd xyz

Przejście do katalogu xyz znajdującego się w obecnym katalogu roboczym.

cd ..

cd ..

lub

cd..

Przejście do nadrzędnego katalogu.

ls

lub

ls -la

dir /w

lub

dir

Wylistowanie zawartości katalogu.

cd /

cd \

Przejście do głównego katalogu dysku lub systemu plików.

C:

D:

itp.

Zmiana obecnego dysku na podany [4].

Uruchomiona aplikacja domyślnie dziedziczy katalog roboczy po swoim rodzicu (np. po interpreterze poleceń), dzięki czemu wszelkie operacje na systemie plików zazwyczaj przeprowadza się, nawigując po katalogach (tj. zmieniając katalog roboczy interpretera) i posługując się ścieżkami względnymi.

1.5. Zmienne środowiskowe

Zmienne środowiskowe (environment variables) są niewielkimi, tekstowymi wartościami, w których najczęściej przechowuje się pewne ustawienia, z których korzystają wywoływane aplikacje lub niektóre funkcje biblioteczne. Przykładowe zmienne środowiskowe możemy zobaczyć poniżej:

$ env

SHELL=/bin/bash

VTE_VERSION=3409

TERM=xterm

PATH=/usr/bin:/bin:/usr/sbin:/usr/local/sbin

PWD=/tmp

LANG=en_US.UTF-8

HOME=/home/gynvael

LANGUAGE=en_US:en

[...]

> set

ALLUSERSPROFILE=C:\ProgramData

APPDATA=C:\Users\gynvael\AppData\Roaming

BXSHARE=d:\bin\bochs-2.6

COMMANDER_DRIVE=C:

COMMANDER_EXE=C:\totalcmd\TOTALCMD64.EXE

COMMANDER_INI=C:\Users\gynvael\wincmd.ini

COMMANDER_PATH=C:\totalcmd

CommonProgramFiles=C:\Program Files\Common Files

[...]

Z reguły w systemie istnieje możliwość zdefiniowania domyślnego zestawu zmiennych środowiskowych[8], natomiast w praktyce każdy proces posiada ich kopię, którą otrzymuje od procesu-rodzica i którą może swobodnie modyfikować – w takim wypadku procesy potomne domyślnie dziedziczą właśnie tę zmodyfikowaną kopię. Proces-rodzic może również zdefiniować dla uruchamianego programu całkowicie odrębny zestaw zmiennych środowiskowych, niezależny od otrzymanych bądź domyślnych zmiennych. Należy jednak zaznaczyć, że zmienne są kopiowane w momencie uruchomienia procesu potomnego – oznacza to, że proces-rodzic nie będzie mógł modyfikować zmiennych środowiskowych procesu potomnego po jego uruchomieniu, ponieważ ten operował będzie na własnej kopii. Analogicznie proces potomny nie może zmienić wartości danej zmiennej środowiskowej w bloku procesu-rodzica. Z tego względu zmienne środowiskowe nie mogą służyć za metodę komunikacji między dwoma procesami[9], a jedynie do przekazania pewnych parametrów w momencie uruchomienia procesu.

Podobnie jak w przypadku cwd, interpretery poleceń posiadają zestaw rozkazów do modyfikacji zmiennych środowiskowych interpretera, które zostaną odziedziczone przez uruchamiane aplikacje. Dodatkowo interpretery często korzystają ze zmiennych środowiskowych jako ze zmiennych wewnętrznych w skryptach. W takim wypadku niektóre interpretery (np. Bash) umożliwiają określenie, które zmienne powinny być przekazywane procesom potomnym, a które powinny być dostępne jedynie z poziomu interpretera lub jego skryptów.

Tabela 2 zawiera przykładowe polecenia operujące na zmiennych środowiskowych.

Tabela 2. Przykładowe polecenia operujące na zmiennych środowiskowych

Bash

cmd.exe

Opis

export a=xyz

lub

export a

a=xyz

set a=xyz

Ustawienie zmiennej środowiskowej a na wartość xyz.

W przypadku Bash samo export a powoduje ustawienie „bitu dziedziczenia” dla dotychczas lokalnej zmiennej a.

a=xyz

Ustawienie zmiennej a, która nie zostanie przekazana procesom potomnym, na wartość xyz.

a=xyz ./program

Uruchomienie programu program oraz przekazanie mu zmiennej środowiskowej a. Po zakończeniu programu zmienna ta nie jest widoczna w środowisku.

unset a

set a=

Usunięcie zmiennej środowiskowej a.

export

lub

env

lub

printenv

lub

declare -xp

set

Wypisanie wszystkich zmiennych środowiskowych (które otrzyma proces potomny).

declare -p

Wypisanie wszystkich zmiennych środowiskowych i lokalnych.

Jeśli chodzi o same zmienne środowiskowe i ich znaczenie, to kilka przykładów znajdziemy poniżej:

PATH – określa, w jakich katalogach mają być m.in. poszukiwane pliki wykonywalne do uruchomienia (w przypadku podania jedynie nazwy programu z pominięciem ścieżki). Zmienna ta jest wykorzystywana przez wiele aplikacji oraz funkcji API systemu. W systemach z rodziny Windows separatorem, w przypadku podania większej liczby katalogów, jest średnik, natomiast w systemach unixowych standardowo jest to dwukropek. Zmienna ta jest o tyle istotna z punktu widzenia programowania, że warto zawrzeć w niej wszelkie katalogi z kompilatorami i interpreterami, z jakich się korzysta[10].

PROMPT (cmd.exe), PS1 i PS2 (Bash) – definiują tzw. znak zachęty (command prompt) w interpreterze poleceń.

USERPROFILE (Windows), HOME (GNU/Linux) – określa ścieżkę katalogu domowego użytkownika.

COMSPEC (Windows) – zmienna wykorzystywana przez funkcję system ze standardowej biblioteki C pod systemem Windows (msvcrt.dll) do określenia, który interpreter poleceń powinien zostać wywołany.

LD_PRELOAD (GNU/Linux) – określa dynamiczne biblioteki, które powinny zostać załadowane przed wszystkimi innymi bibliotekami, wymaganymi przez uruchamiany program (oznacza to, że funkcje wyeksportowane w tych bibliotekach zostaną użyte w miejsce funkcji o tej samej nazwie znajdujących się w załadowanych później bibliotekach).

LD_LIBRARY_PATH (GNU/Linux) – określa ścieżki, w których mogą znajdować się wymagane przez program biblioteki dynamiczne.

Zachęcam czytelników do wylistowania zmiennych środowiskowych w swoim systemie i próby określenia znaczenia każdej z nich (ćwiczenie [CON:what's-this-what's-that]).

Do zmiennych środowiskowych można odwoływać się również z linii poleceń w interpreterze (oraz skryptach interpretera). Obrazują to następujące przykłady:

Bash:

$ test="Some example text."

$ echo "{$test}"

Some example text.

$ echo "SomeChar&dollar;{test}AnotherChar"

SomeCharSome example text.AnotherChar

$

cmd.exe:

> set test=Some example text.

> echo %test%

Some example text.

> echo SomeChar%test%AnotherChar

SomeCharSome example text.AnotherChar

Delayed expansion w cmd.exe [BEYOND]

W przypadku interpretera cmd.exe istnieje jeszcze jeden mechanizm odwoływania się do zmiennych środowiskowych – tzw. „opóźnione rozwinięcie” (delayed expansion), oznaczane znakami wykrzykników. Korzysta się z niego w zasadzie tylko w przypadku bardziej skomplikowanych skryptów, używających bloków kodu (oznaczanych nawiasami okrągłymi). O „opóźnionym rozwinięciu” możemy myśleć jako o standardowych odwołaniach do zmiennych znanych z różnych języków programowania – zaskoczeniem wydaje się, że to właśnie „normalne” (tj. oznaczone znakami procentów) rozwinięcie wymaga pewnego wyjaśnienia.

W przypadku skryptów .bat (zwanych czasem skryptami batch lub skryptami wsadowymi) standardowe rozwinięcie działa podobnie do preprocesora z języków C/C++, czyli podmiana zmiennej na jej wartość następuje na samym początku przetwarzania danego bloku (lub linii) skryptu. Oznacza to, że jeśli w danym bloku nastąpi zmiana wartości zmiennej, to zmiana ta nie zostanie odzwierciedlona przy kolejnym użyciu zmiennej w tym samym bloku (w przeciwieństwie do zmiennych rozwijanych z opóźnieniem, których wartość zostaje podstawiona dopiero w momencie faktycznego użycia).

Stwierdzenie to najlepiej ilustruje poniższy przykład, wykorzystujący obydwa typy odwołania do zmiennej test, której wartość jest modyfikowana wewnątrz bloku kodu:

@echo off

setlocal enabledelayedexpansion

set test=Some example text.

(

echo %test%, !test!

set test=Switching text to this.

echo %test%, !test!

)

Wynik działania skryptu jest następujący:

Some example text., Some example text.

Some example text., Switching text to this.

Wykomentowując instrukcję @echo off, można zaobserwować, jak wyglądają kolejne uruchamiane linie i bloki skryptu (interpreter je wypisze bezpośrednio przed wykonaniem) po fazie rozwinięcia zmiennych oznaczonych procentami:

> rem @echo off

> setlocal enabledelayedexpansion

> set test=Some example text.

> (

echo Some example text., !test!

set test=Switching text to this.

echo Some example text., !test!

)

Some example text., Some example text.

Some example text., Switching text to this.

W powyższym listingu możemy zaobserwować, że bezpośrednio przed wykonaniem ostatniego bloku kodu rozwinięcie %test% zostało już wykonane.

Co ciekawe, istnienie dwóch różnych mechanizmów rozwijania zmiennych pozwala na tworzenie całkiem ciekawych skryptów, które mogą np. emulować obiektowość [5][6].

1.6. Skrypt startowy

Co oczywiste, modyfikowanie zmiennych środowiskowych (np. PATH) przy każdym uruchomieniu interpretera jest zdecydowanie uciążliwe. Zamiast tego można albo zmodyfikować zmienne domyślne w systemie, albo skorzystać ze skryptu startowego, który jest uruchamiany przy starcie interpretera. W przypadku cmd.exe pod systemami z rodziny Windows skrypt startowy można stworzyć w dowolnym miejscu i podać jego ścieżkę w rejestrze systemowym:

\Software\Microsoft\Command Processor\AutoRun (REG_SZ)

Wartość można dodać zarówno dla wszystkich użytkowników (HKEY_LOCAL_MACHINE), jak i tylko dla siebie (HKEY_CURRENT_USER). Osobiście zazwyczaj umieszczam skrypt w C:\Users\gynvael\cmdstart.bat i ma on treść zależną głównie od zainstalowanych interpreterów i kompilatorów, np.:

@echo off

color a

rem Additional command-line binaries

set PATH=%PATH%;d:\commands;d:\bin\virtualbox;d:\bin\reskit2003;

rem MinGW GCC

set PATH=%PATH%;d:\bin\gcc\bin

rem Python

set PATH=%PATH%;d:\bin\Python27_64;d:\bin\pypy-2.2.1-win32

rem PHP

set PATH=%PATH%;d:\bin\php

rem Bochs

set BXSHARE=d:\bin\bochs-2.6

set PATH=%PATH%;d:\bin\bochs-2.6

rem Sysinternals

set PATH=%PATH%;d:\bin\SysinternalsSuite

rem Go

set GOROOT=d:\bin\go

set PATH=%PATH%;d:\bin\go\bin

prompt gynvael:haven-windows$g

W przypadku Bash i systemów unixowych skrypt startowy nosi nazwę .bashrc i znajduje się w katalogu domowym użytkownika (w praktyce Bash uruchamia plik .bash_profile, który jednak zwyczajowo wywołuje .bashrc). Na przykład moje zmiany w nim zazwyczaj ograniczają się do modyfikacji znaku zachęty oraz dopisania jednego lub kilku aliasów:

[...]

PATH=$PATH:~/commands:/usr/sbin:/usr/local/sbin

PS1='\[\033[0;31m\]`date +%T` \[\033[1;34m\]\u\[\033[m\]:\
[\033[1;30m\]\h\[\033[0;32m\]> \[\033[1;32m\]

alias c='g++ -Wall -Wextra'

Warto zapoznać się bliżej z tworzeniem bardziej złożonych skryptów – w praktyce nieraz mogą one okazać się bardzo przydatne (omówienie konkretnych przypadków wykracza jednak poza zakres książki).

1.7. Konsola okiem programisty

Z punktu widzenia programowania najbardziej podstawową operacją, którą powinien znać każdy programista, jest interakcja ze standardowym wyjściem oraz wejściem. Dla przypomnienia tabela 3 zawiera przykłady operacji na standardowym wyjściu i wejściu w kilku językach.

Tabela 3. Wypisanie wiadomości na stdout i stderr oraz pobranie linii tekstu z stdin

Język

Interakcja z

Przykładowy fragment kodu

Python

stdout

print "Example text"

lub

sys.stdout.write("Example text\n")

stderr

sys.stderr.write("Example text\n")

lub

print>>sys.stderr, "Example text" # 2.7

lub

print("Example text", file=sys.stderr) # 3

stdin

line = raw_input() # 2.7

lub

line = sys.stdin.readline()

C / C++

stdout

puts("Example text")

lub

fputs("Example text", stdout);

stderr

fputs("Example text", stderr);

lub

fwrite("Example text", 1, 12, stderr);

stdin

fgets(buffer, buffer_size, stdin);

lub

gets_s(buffer, buffer_size);[11]

lub

scanf("%15[^\n]", buffer); // dla char buffer[16]

C++

stdout

std::cout << "Example text\n";

stderr

std::cerr << "Example text\n";

stdin

std::getline(std::cin, string_object);

lub

std::cin.getline(buffer, buffer_size);

Java

stdout

System.out.println("Example text\n");

stderr

System.err.println("Example text\n");

stdin

BufferedReader in = new BufferedReader(

new InputStreamReader(System.in));

line = in.readLine();

Standardowe wyjście i wejście w aplikacjach okienkowych [BEYOND]

Warto wspomnieć, że pod systemami z rodziny Windows również aplikacje okienkowe (tj. niekorzystające z konsoli) mogą użyć standardowego wyjścia lub wejścia. Oczywiście z powodu braku zaalokowanej dla nich konsoli interakcja z stdin/stdout ogranicza się jedynie do przekierowań, np.:

#include <stdio.h>

#include <windows.h>

int main(void) {

char buffer[128] = "You have entered: ";

scanf("%109s", buffer + 18);

MessageBoxA(NULL, buffer, "Example", MB_OK);

return 0;

}

Kompilacja i uruchomienie:

> gcc test.c -mwindows

> echo Example text | a.exe

Zdarza się, iż podczas tworzenia aplikacji docelowo okienkowych korzysta się z wypisywania pomocniczych informacji (tzw. debug messages) na standardowe wyjście. Przed publikacją finalnego produktu następuje jedynie przestawienie subsystemu na okienkowy (tak by konsola nie była alokowana dla tej aplikacji), ale korzystając z przekierowań, można nadal dostać się do wypisywanych informacji.

Drugie w kolejce są zazwyczaj argumenty programu – co prawda aplikacje okienkowe również ich używają, niemniej jednak są one zdecydowanie najczęściej spotykane w przypadku programów konsolowych. Dostęp do argumentów odbywa się przeważnie na jeden z dwóch sposobów: gdy główna funkcja programu otrzymuje tablicę argumentów w jednym z parametrów lub gdy dostęp do tej tablicy zachodzi przy użyciu standardowej biblioteki albo funkcji systemowych. Tabela 4 wskazuje, gdzie można znaleźć tablicę argumentów w kilku przykładowych językach.

Tabela 4. Dostęp do argumentów programu

Język

Metoda

Przykładowy kod

Python

std. biblioteka

import sys

print sys.argv

C / C++

main

#include <stdio.h>

int main(int argc, char **argv) {

for (int i = 0; i < argc; i++) {

printf("%i: %s\n", i, argv[i]);

}

return 0;

}

C / C++

(WinAPI)

API systemowe

#include <windows.h>

#include <stdio.h>

int main(void) {

puts(GetCommandLine());

// Patrz również: CommandLineToArgvW

return 0;

}

Java

main

class args {

public static void main(String[] args) {

for(int i = 0; i < args.length; i++) {

System.out.println(i + ": " + args[i]);

}

}

}

Sytuacja ze zmiennymi środowiskowymi wygląda podobnie jak z argumentami, choć dostęp do nich zazwyczaj odbywa się poprzez funkcję ze standardowej biblioteki w danym języku – pewnym wyjątkiem są języki C i C++, w których funkcja main w niektórych implementacjach może zostać zadeklarowana z trzema argumentami i otrzymać zmienne środowiskowe w trzecim z nich. Tabela 5 zawiera przykłady odwołań do zmiennych środowiskowych w kilku językach:

Tabela 5. Dostęp do zmiennych środowiskowych

Język

Metoda

Przykładowy kod

Python

std. biblioteka

print os.environ['PATH']

lub

print os.getenv('PATH')

C / C++

main

#include <stdio.h>

int main(int argc, char **argv, char **envp) {

for (int i = 0; envp[i] != NULL; i++) {

printf("%i: %s\n", i, envp[i]);

}

return 0;

}

C / C++

std. biblioteka

#include <stdio.h>

#include <stdlib.h>

int main(void) {

puts(getenv("PATH"));

return 0;

}

Java

std.biblioteka

class env {

public static void main(String[] args) {

System.out.println(System.getenv("PATH"));

// Patrz również: os.getenv()

}

}

Warto wspomnieć jeszcze o kilku innych metodach dostępu do zmiennych środowiskowych zależnych od systemu operacyjnego:

W niektórych systemach opartych na jądrze Linux początkowe zmienne środowiskowe danego procesu znajdują się również w pseudopliku /proc/<pid>/environ. W języku C w przypadku pewnych systemów unixowych istnieje zmienna globalna char **environ lub char **__environ, która posiada tablicę zmiennych środowiskowych analogiczną do envp.

WinAPI posiada dodatkowe funkcje do operowania na zmiennych środowiskowych – np. GetEnvironmentVariable oraz CreateEnvironmentBlock.

Dla wszystkich wymienionych funkcji pobierających zmienne środowiskowe, rozpoczynających się od get* lub Get*, istnieją również odpowiedniki modyfikujące blok zmiennych środowiskowych danego procesu, których nazwy zazwyczaj brzmią identycznie, ale zaczynają się od czasowników: set, put lub unset. Oprócz tego, jak wspomniałem wcześniej, można zdefiniować zupełnie nowy blok zmiennych środowiskowych dla procesu potomnego podczas jego tworzenia – umożliwiają to poszczególne funkcje uruchamiające programy, np. execve czy CreateProcess.

Ponadto systemy operacyjne, jak i same konsole, często udostępniają możliwość dodatkowego konfigurowania terminalu, sposobu wyświetlania danych czy odbioru innych zdarzeń od użytkownika (np. pozycji myszki). Tabela 6 zawiera krótką wskazówkę, gdzie szukać informacji o API konsolowym.

Tabela 6. Przykładowe funkcje i biblioteki służące do bezpośredniej interakcji z konsolą

System lub Język

Funkcje lub biblioteka

Python

(GNU/Linux)

Moduły termios oraz tty.

C/C++

(GNU/Linux)

Pseudoplik /dev/tty, a także nagłówki termios.h oraz sys/ioctl.h.

C/C++ i

(WinAPI)

Funkcje z „Console” w nazwie, np. SetConsoleMode, FillConsoleOutputAttribute, WriteConsoleOutput itp.

Java

Klasa java.io.Console.

Kończąc ten rozdział, chciałbym jeszcze raz gorąco zachęcić czytelników do zapoznania się z możliwościami konsoli i wybranym interpreterem poleceń.

Ćwiczenia

[CON:start-script]

Stwórz lub zmodyfikuj skrypt startowy interpretera poleceń, z którego korzystasz.

[CON:what's-this-what's-that]

Uruchom interpreter i wyświetl zmienne środowiskowe, a następnie postaraj się określić znaczenie każdej z nich, tj. przez jaki program lub funkcję jest dana zmienna wykorzystywana.

Bibliografia

http://coldwind.pl/s/c1r1

[1] Redirections, Bash Reference Manual, http://www.gnu.org/software/bash/manual/bash.html#Redirections

[2] Using command redirection operators, Microsoft Developer Network, https://technet.microsoft.com/en-us/library/bb490982.aspx

[3] GnuWin32, http://gnuwin32.sourceforge.net/

[4] Chen R., Why does each drive have its own current directory?, 2010, http://blogs.msdn.com/b/oldnewthing/archive/2010/10/11/10073890.aspx

[5] Coldwind G., Skrypty .BAT i programowanie obiektowe, 2009, http://gynvael.coldwind.pl/?id=123

[6] Coldwind G., OpenGL w skryptach .BAT, 2009, http://gynvael.coldwind.pl/?id=127