<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Bash on Morfitronik</title>
    <link>https://morfikov.github.io/tags/bash/</link>
    <description>Recent content in Bash on Morfitronik</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>pl-PL</language>
    <lastBuildDate>Sun, 10 Jul 2016 19:14:31 +0000</lastBuildDate><atom:link href="https://morfikov.github.io/tags/bash/feed.xml" rel="self" type="application/rss+xml" />
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak zweryfikować status poleceń w pipe</title>
      <link>https://morfikov.github.io/post/zweryfikowac-status-polecen-pipe/</link>
      <pubDate>Sun, 10 Jul 2016 19:14:31 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/zweryfikowac-status-polecen-pipe/</guid>
      <description>&lt;p&gt;Ja zbytnio się nie nadaję na programistę ale czasem jakieś trzeciorzędne skrypty nawet potrafię
napisać. Problem ze skryptami jest taki, że mogą one nie do końca działać jak należy. Zwykle w
takich przypadkach, skrypt zwraca jakiś kod wyjścia. Z reguły też jest on inny od 0, który z kolei
oznacza, że skrypt został wykonany prawidłowo. Załóżmy teraz, że wywołujemy szereg poleceń. Każde z
nich przekierowuje swoje wyjście na wejście innego polecenia przy pomocy znaku &lt;code&gt;|&lt;/code&gt; (pipe) . Jak w
takim przypadku ustalić czy wszystkie z tych poleceń w łańcuchu wykonały się poprawnie? W tym wpisie
postaramy się odpowiedzieć na to pytanie.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Jak wypakować każde archiwum</title>
      <link>https://morfikov.github.io/post/jak-wypakowac-kazde-archiwum/</link>
      <pubDate>Fri, 20 Nov 2015 15:15:30 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/jak-wypakowac-kazde-archiwum/</guid>
      <description>&lt;p&gt;Archiwum &lt;code&gt;.tar.gz&lt;/code&gt; czy też każde inne, np. &lt;code&gt;.zip&lt;/code&gt; lub &lt;code&gt;.rar&lt;/code&gt; , jest bardzo użyteczne przy
przesyłaniu przez sieć plików między wieloma maszynami. Nie dość, że zaoszczędzają nam sporo
transferu, to jeszcze do tego operujemy na jednym pliku. Problem z tymi wszystkimi rodzajami
archiwów jest taki, że do każdego z nich mamy inne narzędzia. Zwykle też każde z tych narzędzi ma
inne opcje, które taką paczkę potrafią wypakować. Przydałby się zatem sposób, który ogarnąłby
wypakowanie różnych archiwów i sprowadzałby się do wydania w terminalu tylko jednego polecenia, bez
potrzeby pamiętania nazw narzędzi i ich opcji. W tym wpisie postaramy się coś takiego
zaimplementować na swoich linux&#39;ach.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Kolorowanie wyjścia terminala</title>
      <link>https://morfikov.github.io/post/kolorowanie-wyjscia-terminala/</link>
      <pubDate>Mon, 09 Nov 2015 14:57:01 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/kolorowanie-wyjscia-terminala/</guid>
      <description>&lt;p&gt;Każdy terminal jest w stanie wyświetlić tekst w kilku kolorach. Zwykle mamy ich do dyspozycji 8
lub 16. Niektóre terminale potrafią rozróżniać nawet 256 kolorów. Niemniej jednak, kolor całego
tekstu jaki jest wyświetlany w terminalu jest zwykle jednolity i nie ma w nim praktycznie żadnych
urozmaiceń. W taki sposób mamy czarny tekst i białe tło. Jako, że te terminale są w stanie
wyświetlić więcej kolorów, to dla większej czytelności przydałoby się skonfigurować kolorowanie
wyjścia takich narzędzi jak &lt;code&gt;ls&lt;/code&gt; , &lt;code&gt;grep&lt;/code&gt; czy &lt;code&gt;man&lt;/code&gt; . Jesteśmy w stanie pokolorować także szereg
innych rzeczy i o tym będzie ten poniższy wpis.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Uzupełnianie poleceń w bash (bash completion)</title>
      <link>https://morfikov.github.io/post/uzupelnianie-polecen-w-bash/</link>
      <pubDate>Sat, 07 Nov 2015 16:56:11 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/uzupelnianie-polecen-w-bash/</guid>
      <description>&lt;p&gt;Bash nie nadaje się dla nieco bardziej zaawansowanych użytkowników linux&#39;a. Najbardziej odczuwalnym
elementem bash&#39;a jest brak uzupełniania poleceń za pomocą klawisza Tab . Nie mówimy tutaj o
przeszukiwaniu zmiennej &lt;code&gt;$PATH&lt;/code&gt; pod kątem dopasowań pliku wykonywalnego do tego co wpisujemy
aktualnie w terminalu. Nie chodzi też o uzupełnianiu ścieżek podawanych do &lt;code&gt;cd&lt;/code&gt; ale o opcje, które
jakiś program może przyjąć jako argument. Zwykle musimy się uczyć ich na pamięć lub zaglądać do
help&#39;a czy manuala. Możliwe jest jednak skorzystanie z dodatku zwanego &lt;a href=&#34;https://en.wikipedia.org/wiki/Command-line_completion&#34;&gt;bash
completion&lt;/a&gt;, który w sporej części przypadków
potrafi dostarczyć dość zaawansowane uzupełnianie poleceń, którymi się posługujemy na co dzień. Ten
wpis ma na celu pokazanie jak włączyć ten cały mechanizm i uprościć sobie nieco życie podczas pracy
w terminalu.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Plik .bashrc, czyli konfiguracja bash&#39;a</title>
      <link>https://morfikov.github.io/post/plik-bashrc-czyli-konfiguracja-basha/</link>
      <pubDate>Sat, 07 Nov 2015 15:23:38 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/plik-bashrc-czyli-konfiguracja-basha/</guid>
      <description>&lt;p&gt;Jakiś czas temu opisywałem &lt;a href=&#34;https://morfikov.github.io/post/plik-bash_history-czyli-historia-polecen-basha/&#34;&gt;konfigurację historii bash&#39;a w pliku .bash_history&lt;/a&gt; ale możliwości
konfiguracyjne bash&#39;a nie ograniczają się jedynie do zmiany kilku parametrów czy zmiennych
dotyczących historii wpisywanych w terminalu poleceń. Ten wpis ma na celu zebranie tych bardziej
użytecznych funkcjonalności bash&#39;a, które często są wykorzystywane przez użytkowników linux&#39;a i
dopisywane w pliku &lt;code&gt;.bashrc&lt;/code&gt; .&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Plik .bash_history, czyli historia poleceń bash&#39;a</title>
      <link>https://morfikov.github.io/post/plik-bash_history-czyli-historia-polecen-basha/</link>
      <pubDate>Fri, 06 Nov 2015 01:08:18 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/plik-bash_history-czyli-historia-polecen-basha/</guid>
      <description>&lt;p&gt;Operowanie na linux&#39;ie wiąże się w dużej mierze z wpisywaniem poleceń do terminala. Każdy kto
spędził trochę czasu w tym systemie, wie, że do komfortowej pracy potrzebny jest przyzwoicie
skonfigurowany shell. Domyślnym shell&#39;em w debianie, jak i wielu innych linux&#39;ach, jest bash. Każdy
z nas na początku wpisywał wszystkie polecenia ręcznie i nawet nie wiedział, że istnieje coś takiego
jak uzupełnianie pewnych fraz, czy też nazw, przy pomocy klawisza Tab . Z czasem nasz stopień
poznania jakiejś dystrybucji linux&#39;a osiąga pewien dość zaawansowany poziom i wpisywanie za każdym
razem tych samych poleceń jedynie spowalnia naszą pracę. Dlatego właśnie bash, podobnie jak i inne
shell&#39;e, mają swoje pliki konfiguracyjne, w których to możemy &lt;a href=&#34;https://www.gnu.org/software/bash/manual/bash.html#Shell-Variables&#34;&gt;dostosować naprawdę sporo rzeczy&lt;/a&gt;.
W tym wpisie skupimy się na historii poleceń, która trafia do pliku &lt;code&gt;.bash_history&lt;/code&gt; w katalogu
domowym każdego użytkownika w systemie.&lt;/p&gt;</description>
    </item>
    
    <item>
	  <author>Mikhail Morfikov</author>
      <title>Automatyczne wylogowanie użytkownika z konsoli</title>
      <link>https://morfikov.github.io/post/automatyczne-wylogowanie-uzytkownika-z-konsoli/</link>
      <pubDate>Wed, 17 Jun 2015 22:06:51 +0000</pubDate>
      
      <guid>https://morfikov.github.io/post/automatyczne-wylogowanie-uzytkownika-z-konsoli/</guid>
      <description>&lt;p&gt;Każdemu z nas zdarzyło się zostawić włączoną konsolę, na której byliśmy zalogowani jako
administrator systemu root. Być może nie zdajemy sobie sprawy jak często potrafimy popełnić tego
typu gafę. Jedną z metod obrony jest oczywiście wyłączenie konta root w systemie i korzystanie z
&lt;a href=&#34;https://pl.wikipedia.org/wiki/Sudo&#34;&gt;sudo&lt;/a&gt;. Ja jednak wolę inne rozwiązanie, które zakłada
ograniczenie czasu bezczynności, po którym to użytkownik zostanie automatycznie wylogowany.&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>
