Strona używa cookies (ciasteczek). Dowiedz się więcej o celu ich używania i zmianach ustawień. Korzystając ze strony wyrażasz zgodę na używanie cookies, zgodnie z aktualnymi ustawieniami przeglądarki.    X

Zrozumieć powłokę tekstową - pozostałe strumienie

Kontynuując wątek poświęcony powłoce tekstowej chciałbym tym razem przybliżyć nieco pozostałe strumienie, z których korzystamy podczas normalnej pracy z powłoką bash. Artykuł ten jest bezpośrednią kontynuacją wpisu Zrozumieć powłokę tekstową - standardowy strumień wyjściowy. Dlatego będą tutaj wykorzystane informacje poznane wcześniej.
Na początek przypomnę, że w poprzednim wpisie wymieniłem trzy standardowe strumienie: 
- wejściowy (STDIN) 
- wyjściowy (STDOUT) 
- błędów (STDERR) 
Wcześniej opisany został standardowy strumień wyjściowy, dlatego czas na opisanie pozostałych.

Każdy program musi skądś popierać dane, zazwyczaj z pliku lub bezpośrednio wpisywane przez użytkownika. W poprzednim wpisie zaznaczyłem również, że każdy proces uruchomiony w systemie Linux jest standardowo połączony z terminalem poprzez trzy wymienione wcześniej strumienie. Domyślnym miejscem, skąd procesy pobierają dane jest klawiatura, dlatego że standardowy strumień wejściowy (STDIN) jest tak domyślnie skonfigurowany. Jednak tak jak w przypadku STDOUT można go zmodyfikować za pomocą odpowiedniego operatora "lewy_ptaszek".

Uwaga: W związku z tym, że edytor bloga nie akceptuje jednoczesnego korzystania ze znaków lewego i prawego"ptaszka", bo jest to interpretowane, a nie działa wpisywanie kodów znaków specjalnych to jestem zmuszony zastąpić jednego z nich tekstem "lewy_ptaszek". Dlatego w każdym miejscy w tekście, gdzie będzie tekst "lewy_ptaszek" oznaczać będzie znak lewego ptaszka. (jego kod HTML to <)

r   e   k   l   a   m   a

Zacznijmy od stworzenia pliku z tekstem za pomocą metody poznanej w poprzednim artykule.

echo dobreprogramy.pl to moja ulubiona strona internetowa > plik.txt

Teraz tekst zawarty w tym pliku przekażemy do programu wc strumieniem. wc to bardzo prosta aplikacja, która zlicza nam ilość wierszy, wyrazów i liter w podanym tekście. Od razu nadmienię, że program ten działa również na samych plikach, bez potrzeby kierowania strumieni, ale wtedy dodatkowo wyświetlana jest nam nazwa pliku. Ale na potrzeby pokazania zasady działania my przekażemy to zdanie strumieniem. Dlatego należy wpisać następującą komendę. 

chomik@zhp:~$ wc lewy_ptaszek plik.txt
 1  6 53

Wynikiem programu są liczby informujące nas, że tekst w pliku plik.txt składa się z jednego wiersza, ma sześć wyrazów i 53 znaki. Ale czy możemy taki wynik zapisać w innym pliku? Oczywiście tak, po prostu na końcu linii trzeba dopisać poznaną w poprzednim artykule komendę.

chomik@zhp:~$ wc lewy_ptaszek plik.txt > plik2.txt
chomik@zhp:~$ 
chomik@zhp:~$ cat plik2.txt 
1 6 53

Jak widać wynik programu nie został wyświetlony, bo przekierowaliśmy go do pliku plik2.txt. Wynik polecenia cat to potwierdza.

Pozostał jeszcze jeden strumień - standardowy strumień błędów (STDERR) - który musimy nauczyć się obsługiwać. Ale zanim to zrobimy to musimy wprowadzić pojęcie deskryptora pliku. Ta tajemnicza nazwa to nic innego jak nasze wcześniej poznane strumienie, z tą różnicą, że teraz wszystko wrzucamy do jednego worka i nazywamy jedną nazwa. Zatem STDIN jest deskryptorem, STDOUT również, no i STDERR też. Mają one domyślnie przypisane liczby (indeksy): 
- STDIN - 0 
- STDOUT - 1 
- STDERR - 2

STDERR służy do wyświetlania błędów - domyślnie na ekranie. Ten deskryptor też oczywiście możemy przekierować. Zatem wygenerujmy przykład błędu pingując nieistniejącego hosta. 

chomik@zhp:~$ ping niesitniejacy_host.com 
ping: unknown host niesitniejacy_host.com

Otrzymaliśmy informacje o błędzie. Teraz wynik polecenie spróbujmy błędnie (zaraz powiem dlaczego) przekierować do pliku modyfikując STDOUT poznaną wcześniej metodą.

chomik@zhp:~$ ping niesitniejacy_host.com > ping.txt 
ping: unknown host niesitniejacy_host.com 
chomik@zhp:~$ cat ping.txt

Ku naszemu zdziwieniu informacja o tym, że host nie istnieje wyświetliła się na ekranie, mimo że strumień został przekierowany to pliku ping.txt, a ten jest pusty. Jest tak dlatego, że otrzymaliśmy informację o błędzie, która jest kierowana na standardowy strumień błędów (STDERR), a nie wyjściowy (STDOUT). Żeby przekierować błędy do pliku musimy użyć numeru deskryptora. 

chomik@zhp:~$ ping niesitniejacy_host.com 2> errors.txt 
chomik@zhp:~$ 
chomik@zhp:~$ cat errors.txt 
ping: unknown host niesitniejacy_host.com

Jak widać błędy zostały przekierowane do pliku errors.txt za pomocą operatora "2>", gdzie "2" to numer deskryptora, a ">" to operator przekierowania strumienia. Wnikliwi zapytają teraz dlaczego przy STDOUT nie trzeba było wpisywać numeru deksryptora (1)? Odpowiedzią jest to, że to zwykłe uproszczenie (które zresztą wyszło z czasem), w praktyce kto chce może używać operatora "1>" - operator ">" jest równoważny z "1>".

A co zrobić jeżeli chcemy zapisać zarówno wyniki polecenia, jak i błędy do dwóch różnych plików? Nic prostszego. Wystarczy przekierować oba deskryptory. 

ping niesitniejacy_host.com 1> wynik.txt 2> errors.txt 
lub 
ping niesitniejacy_host.com > wynik.txt 2> errors.txt 
(z pominięciem jedynki przy STDOUT)

Utworzone zostaną dwa pliki: 
wynik.txt - z wynikiem mojego polecenia 
errors.txt - z ewentualnymi błędami

A co, jeżeli nie chcę niczego wyświetlać na ekranie, tylko oba strumienie (STDOUT i STDERR) chcę zapisać do tego samego pliku? Należy wszystkie deskryptory przekierować do jednego pliku stosując operator "&>". 

ping niesitniejacy_host.com &> wynik.txt

Przykładów można mnożyć w nieskończoność. Tutaj zaprezentowałem tylko te podstawowe, a to tylko kropla w morzu. Ale prawda jest taka, że w większości wypadków to wystarczy.
Istnieje oczywiście możliwość korzystania z niestandardowych deskryptorów, bo można np. przekierować ten sam strumień do wielu (więcej niż dwóch) plików jednocześnie, ale to już jest zbyt skomplikowane jak na początek.
Ogólnie w tym artykule chciałem pokazać, że w powłoce bash można strumienie łączyć i kierować w różne miejsca, w zależności od potrzeb. Przyda się to później, gdy będziemy w praktyce je wykorzystywali.
Dlatego zachęcam do wnikliwej analizy tego artykułu, bo już niedługo poznamy metody łączenia poleceń w długie ciągi. 

Komentarze