Komputery, oprogramowanie, internet i okolice
Kategorie: Wszystkie | Aplikacje | Blog | Dev | Hacks | Linux | Subversion | Varia | gry | khoomei | książki | mjuzik
RSS

Linux

niedziela, 10 kwietnia 2011

Podczas prac programistycznych często trzeba na szybko wykonać jakiś fragment kodu, lub sprawdzić coś w konsoli. Zdawałoby się, że najprostszym rozwiązaniem jest wykonanie komedy :sh by uruchomić shell, zrobić co się ma do zrobienia i wrócić do VIMa. Ewentualnie zastosować bashowe Ctrl-Z i wrócić za pomocą fg. Niby tak, ale wtedy tracimy z oczu pisany kod, a włączanie za każdym razem, dajmy na to, interpretera Pythona wygodne na pewno nie jest.

Conque Shell - conque_term.vim

Conque Shell - bash w okienku VIMa

Jeśli ktoś nie ma ochoty na taką gimnastykę z pomocą przychodzi Conque Shell pozwalający na uruchomienie terminala w buforze VIMa. Z tego co widzę od wersji 2.0 wspierany jest również system Windows.

Instalacja

By zainstalować plugin najprościej ściągnąć Conque Shell spakowany jako vimball (plik z rozszerzeniem .vba), następnie otworzyć go w VIMie i wykonać :so % - wszystkie pliki zostaną skopiowane do właściwych katalogów, a tagi dla pliku pomocy zostaną wygenerowane. Zawsze też można pobrać zwykłe archiwum i ręcznie skopiować pliki do katalogu ~/.vim/.

Konfiguracja i użytkowanie

Obsługa pluginu Conque Shell jest dziecinnie prosta. Wystarczy wykonać :ConqueTerm [polecenie] by uruchomić dany program w bieżącym oknie. Można też użyć :ConqueTermSplit lub :ConqueTermVSplit by wykonać polecenie w nowym oknie dzieląc je odpowiednio w poziomie lub pionie. Jednak ze względu na brak możliwości ustawienia domyślnego umiejscowienia okna Conque Shell (prawa/lewa strona, góra/dół) ja osobiście wolę ręcznie podzielić okno za pomocą :sp lub :vsp, ustawić pożądany rozmiar i dopiero wtedy otworzyć Conque Shell.

W trybie INSERT sterowanie klawiatury przekazane jest do konsoli, by powrócić do VIMa wystarczy nacisnąć ESC. Jeśli chcemy użyć klawisza ESC w uruchomionym programie należy nacisnąć ten klawisz dwa razy. Ewentualnie można ustawić własny klawisz, za pomocą którego będziemy przełączać sterowanie z Conque Shell spowrotem do VIMa za pomocą:

let g:ConqueTerm_EscKey = '<C-q>'

Jeśli chcemy wysyłać do programu uruchomionego w Conque Shell naciścnięcia klawiszy funkcyjnych musimy ustawić:

let g:ConqueTerm_SendFunctionKeys = 1

Jeśli chcemy przełączać się pomiędzy oknami VIMa bez opuszczania trybu INSERT w Conque należy użyć:

let g:ConqueTerm_CWInsert = 1

By poprawić szybkość działania można w ustawieniach wyłączyć obsługę kolorów, czy też przejść do trybu Fast Mode wyłączającego wszelkie opcje, które mogą spowalniać:

let g:ConqueTerm_Color = 0

let g:ConqueTerm_FastMode = 1

Przydatna może być jeszcze możliwość wykonania aktualnie edytowanego pliku po naciśnięciu F11, wysłanie zawartości aktywnego pliku do ostatnio otwartego okna Conque za pomocą F10, czy też wysłanie zaznaczonego tekstu (w trybie VISUAL!) za pomocą F9.

Werdykt

Jest to rozwiązanie niezwykle ciekawe. Mimo kilku niedoskonałości (na przykład problemy z prawidłowym wyświetlaniem kolorów) radzi sobie bardzo dobrze i bywa niesamowicie przydatne.

Na koniec taki mały żarcik z użyciem Conque Shell...

VIM - Incepcja!

...VIMowa Incepcja jak się patrzy! :)

00:05, kosciak1 , Linux
Link Dodaj komentarz »
poniedziałek, 28 marca 2011

Jak każdy pewnie wie w VIMie dostępne są taby (czy też karty), jednak działają trochę inaczej niż można by się spodziewać. Nie są powiązane z otwartymi plikami (czy raczej buforami), a z określonym layoutem otwartych okien. Szczerze powiedziawszy jakoś nigdy się do nich specjalnie nie przekonałem. Na szczęście jest dostępna wtyczka, która działa dokładnie tak jak można by oczekiwać.

MiniBufExplorer - minibufexpl.vim

VIM plugin - MiniBufExplorer

Mini Buffer Explorer pokazuje listę otwartych buforów w formie listy tabów (kart) znanej z innych programów i pozwala na łatwe poruszanie się pomiędzy nimi.

Instalacja

Oryginalny plugin jest już od dawna nie rozwijany. Na szczęście dostępna jest nowa, aktywnie rozwijana wersja - MiniBufExplorer 6.4 wtyczki, która zawiera poprawki i kilka nowych funkcji. Ściągnięty plik należy umieścić w folderze ~/.vim/plugin/

Konfiguracja i użytkowanie

By otworzyć okno MiniBufExplorera używamy mbe (domyślnie \mbe), lub przełączamy się do jego okna. Następnie za pomocą (Shift)Tab, lub h i l przełączamy się pomiędzy buforami. o, e i Enter otwierają bufor w ostatnio aktywnym oknie, s otwiera bufor dzieląc okno w poziomie, v dzieląc w pionie. d służy do zamknięcia wybranego buforu.

Domyślnie lista buforów wyświetlana jest w formie poziomej linii, jeśli ktoś chciałby wyświetlać je w pionie wystarczy ustawić szerokość okna.

let g:miniBufExplVSplit = 20

Możemy również ustawić kiedy MiniBufExplorer ma się pojawiać (domyślnie gdy otwartych jest więcej niż 1 plik). By okno z listą buforów było otwarte przez cały czas ustawiamy następującą zmienną:

let g:miniBufExplorerMoreThanOne=1

Kolejnymi ciekawymi ustawieniami niezmiernie ułatwiającymi pracę z wieloma oknami na raz są:

let g:miniBufExplMapWindowNavVim = 1
let g:miniBufExplMapWindowNavArrows = 1
let g:miniBufExplMapCTabSwitchBufs = 1
let g:miniBufExplMapCTabSwitchWindows = 1
let g:miniBufExplUseSingleClick = 1

Pozwalające odpowiednio na: przełączanie się pomiędzy oknami za pomocą Ctrl + hjkl, Ctrl + strzałki, przełączanie buforów za pomocą Ctrl-Tab, przełączanie okien za pomocą Ctrl-Tab, otwieranie buforu za pomocą pojedynczego kliknięcia.

Jeśli używamy wtyczek typu NERDTree, czy TagList dobrze jest ustawić poniższą zmienną by nie otwierać buforów w oknie dodatkowego eksploratora.

let g:miniBufExplModSelTarget = 1

Na koniec jeszcze małe ostrzeżenie o denerwującym błędzie. W używanej przeze mnie wersji 6.4.0 próba wyjścia z VIMa, gdy otwarte jest tylko jedno okno plus widoczna jest lista buforów (czy to z użyciem :q, czy ZQ) powoduje jedynie przeładowanie zawartości okna. Należy wtedy użyć :qa lub ręcznie zamknąć MiniBufExploerara za pomocą mbc.

Werdykt

Jest to jeden z pluginów, bez których nie wyobrażam sobie normalnej pracy. Wystarczy jedno spojrzenie i już widać jakie pliki są aktualnie otwarte i które z nich zawierają niezapisane zmiany. Zwłaszcza jeśli ma się ustawione set hidden.

18:36, kosciak1 , Linux
Link Dodaj komentarz »
niedziela, 27 marca 2011

Ależ się porobiło... Zastój to mało powiedziane. Może i blog jeszcze nie umarł, ale powoli zaczął nieprzyjemnie pachnieć. Cóż, czasu coraz mniej, a znalezienie energii gdy za oknem ciemno, zimno i nieprzyjemnie proste nie jest. Na całe szczęście wreszcie nadeszła upragniona wiosna! Tak, wystarczy kilka promyków słońca by powrócił pozytywny nastrój, energia i chęć pisania na blogu!

VIM plugin dnia - nowy cykl

O mojej miłości do VIMa już tu wspominałem, ale poza notką o doborze schematu kolorów i wtyczce CSApprox i tricku z przemapowaniem ESC i CapsLocka za wiele o nim na blogu nie pisałem. Pora więc nadrobić zaległości.

Podczas wiosennych porządków w plikach konfiguracyjnych zauważyłem, że zebrało się już kilkanaście różnych pluginów do VIMa. Bez części z nich nie wyobrażam już sobie efektywnej pracy. Części zupełnie nie kojarzę - sam już nie wiem, czy ich nie używam, czy też nawet nie zdaję sobie sprawy, że używana funkcja to właśnie efekt działania wtyczki. W dodatku co najmniej drugie tyle czeka w zakładkach na sprawdzenie.

Postanowiłem więc przyjrzeć się każdemu pluginowi z osobna, zaktualizować jeśli dostępna jest nowa wersja i napisać o nim kilka zdań.

Stay tuned, start już jutro!

21:38, kosciak1 , Linux
Link Komentarze (4) »
poniedziałek, 12 lipca 2010

Praktycznie od początku mojej przygody z Ubuntu używałem (chyba domyślnego) stylu Human Clearlooks. Kilka razy próbowałem szukać czegoś innego, ale zawsze szybko wracałem. Human Clearlooks jest po prostu taki jak lubię - jasny, miły dla oka, stosunkowo prosty, a przy tym w miarę elegancki. Jedyną rzeczą, która nie do końca mi odpowiadała to obramowania okien, odrobinę zbyt ciężkie (te obramowania przycisków) i zdecydowanie za duże.

xl_cheeselooks_metacity_mod

xl_cheeselooks_metacity_mod

Szukałem czegoś raczej minimalistycznego, jednak niezbyt udziwnionego i czytelnego. Przeglądając Gnome-Look i DeviantArt udało mi się znaleźć kilka ciekawych propozycji, jednak w każdej czegoś mi brakowało.

Najbliżej tego czego poszukiwałem były xl_cheeselooks_metacity (wygląd samego obramowania) oraz Gilouche Squared (wygląd przycisków; niestety nie mam linka pod ręką). Pozostało dokonać odpowiednich przeróbek.

Tak oto powstał xl_clearlooks_metacity_mod. W wielkim skrócie:

  • Szerokość z prawej i lewej strony po 4px, belka tytułu 19px, 1px na dole.
  • Rogi zaokrąglone tylko na górze.
  • Niesymetryczne podświetlanie obramowania.
  • Przyciski prawie jak w Gilouche Squared - ich tło nie jest podświetlane po naciśnięciu, trochę rozjaśnione w nieaktywnych oknach.
  • Zostawiłem ikonę okna - tak jest według mnie czytelniej.
  • Jeśli ktoś uważa, że obramowanie jest zbyt szerokie nie powinno być problemu po zmniejszeniu prawej lub lewej strony do 3px, czy nawet 2px.

To moje pierwsze podejście do modyfikacji skórek metacity, więc jakieś błędy mogą się pewnie pojawić.

By skorzystać z tych obramowań wystarczy rozpakować ściągnięte archiwum do ~/.themes

13:10, kosciak1 , Linux
Link Komentarze (3) »
czwartek, 01 lipca 2010

Teoretycznie większy monitor powinien oznaczać większy komfort pracy na komputerze. Mamy więcej miejsca, więcej na raz widać, możemy uruchomić więcej okienek obok siebie. W praktyce nie jest już tak różowo. Na małym ekranie najwygodniej jest po prostu zmaksymalizować aktualnie używaną aplikację. Przy dużym, panoramicznym ekranie większość aplikacji po zmaksymalizowaniu niestety nie nadaje się do użytku. Pojawia się więc problem wygodnego rozmieszenia i ustawienia rozmiaru okienek.

PyTyle - kafelkowy menadżer okien (dla opornych)

Jednym z rozwiązań powyższego problemu jest zastosowanie kafelkowego menadżera okien (tiling window manager). W przeciwieństwie do "normalnych" menadżerów okien, tutaj okna nie mogą swobodnie się przemieszczać i nakładać na siebie. Zawsze w użyciu jest cała powierzchnia ekranu, szczelnie wypełniona otwartymi programami. Kolejne oknom dynamicznie przyznawane jest miejsce dzieląc ekran w pionie i w poziomie na coś na kształt kafelek.

PyTyle

Jeśli ktoś nie jest na tyle szalony by na co dzień używać kafelkowego menadżera okien z prawdziwego zdarzenia (dwm, wmii, awesome, ratpoison, stumpwm, xmonad, czy i3, by wymienić kilka z nich) może spróbować skorzystać z PyTyle. Nie zastępuje on dotychczas używanego menadżera okien, a jedynie wspomaga go, umożliwiając automatyczne kafelkowanie okien. Nie musimy więc rezygnować z na przykład GNOME i Compiza (lub Metacity), czy KDE do których jesteśmy już przyzwyczajeni. Oto co PyTyle nam oferuje:

  • Włączanie i wyłączanie kafelkowania na każdym pulpicie z osobna (można też ustawić globalny tiling).
  • Kilka algorytmów układania okien do wyboru - podział w pionie, w poziomie, w poziomie w pasach, maksymalizacja okien i ich kaskadowanie.
  • Łatwe przełączanie pomiędzy oknami i zmiana kolejności okien.
  • W przypadku algorytmów podziału w pionie i w poziomie mamy do dyspozycji obszar główny i obszar pozostałych okien. Możemy dodawać okna do obszaru głównego, szybko wybrać okno główne.
  • Łatwa zmiana szerokości/wysokości obszaru głównego.
  • Możliwość wskazania okien, które nie mają podlegać kafelkowaniu.
  • Konfiguracja skrótów klawiaturowych i ustawień poszczególnych algorytmów.
  • Dynamiczne wczytywanie konfiguracji (nie trzeba restartować programu po zmianie ustawień).
  • Obsługa wielu monitorów.

Niestety PyTyle nie jest idealny. Na pewno nie działa tak szybko jak normalne kafelkowe menadżery okien. Algorytm kaskadowy i maksymalizujący okna nie działają do końca tak jakbym chciał by działały. Ustawienie dwa razy tego samego algorytmu z różnymi ustawieniami (np w pionie z podziałem pół na pół i w pionie z podziałem w 2/3 ekranu) nie jest proste i wymaga kombinowania. Czasem też mogą pojawić się problemy z "wykradaniem" skrótów klawiaturowych.

Muszę przyznać, że jest to bardzo ciekawe rozwiązanie. Zyskujemy ciekawy sposób na zarządzanie okien, cały czas pozostając w znanym środowisku. Stosowanie PyTyle nie wymaga aż tak silnej zmiany dotychczasowych przyzwyczajeń jak w przypadku dwm, wmii, czy xmonad. Kusi bardzo, jednak na razie potestuję jeszcze inne rozwiązania, o których wkrótce na blogu.

20:50, kosciak1 , Linux
Link Komentarze (2) »
wtorek, 29 czerwca 2010

Po przesiadce na Linuxa brakowało mi jednego - dobrego odtwarzacza muzycznego. Niby jest spory wybór, ale nie czarujmy się... Testowałem wiele i żaden z nich nie umywał się nawet do mojego ukochanego foobara2000, którego używałem bodajże od wersji 0.6. Zniechęcony i zawiedziony wróciłem do domyślnego w Ubuntu Rhythmboxa tracąc nadzieję na coś choćby zbliżonego do foobara2000. Na szczęście niedawno pojawił się DeaDBeeF i muszę przyznać, że wiara w dobry linuksowy odtarzacz muzyczny wróciła!

DeaDBeeF - odtwarzacz prawie doskonały

Odtwarzacz DeaDBeeF

Pierwszą rzeczą jaka rzuca się w oczy to ascetyczna wręcz prostota. W DeaDBeeF znajdziemy tylko to co konieczne. W końcu odtwarzacz muzyczny ma odtwarzać muzykę, a nie wyglądać. Tu niepotrzebne są żadne fajerwerki. I tak większość czasu jest zminimalizowany. O wiele ważniejsze jest to co siedzi "pod maską". A tu DeaDBeeF ma się czym pochwalić! Oto najważniejsze możliwości programu:

  • Obsługa wielu formatów, w tym bezstratnych, czy formaty trackerów, chiptunes.
  • Obsługa stacji radiowych i podcastów.
  • Wsparcie dla plików .cue!
  • Playlisty w tabach, wybór widocznych kolumn (i definiowania własnych), możliwość grupowania utworów, wyświetlanie okładek.
  • Wsparcie dla ReplayGain.
  • Gapless playback - czyli odgrywanie albumu bez słyszalnych przerw pomiędzy ścieżkami.
  • Edytor tagów.
  • Graficzny equalizer.
  • System wtyczek, można się więc spodziewać, że w przyszłości pojawi się sporo ciekawych dodatków rozszerzających możliwości odtwarzacza.

Na razie jeszcze kilka rzeczy nie działa jak trzeba - miałem problemy z plikami .mpc, czy tworzeniem skrótów klawiszowych. Ale trzeba pamiętać, że to jeszcze dość wczesna wersja programu (testowałem 0.4.1), który jest ciągle dynamicznie rozwijany.

Jeśli ktoś szuka lekkiego, minimalistycznego odtwarzacza o dużych możliwościach na pewno nie będzie zawiedziony!

16:13, kosciak1 , Linux
Link Komentarze (10) »
poniedziałek, 26 kwietnia 2010

Jak powszechnie wiadomo w Linuksie konsola fajna jest. Gdy już poznamy kilka prostych sztuczek okazuje się, że bardzo wiele czynności w konsoli można wykonać o wiele wygodniej i szybciej, niż gdybyśmy mieli przeklikiwać się przez różne okienka. Dziś o jednej z takich sztuczek, jakie oferuje powłoka bash.

Brace expansion

Mechanizm Brace expansion polega na rozwijaniu wyrażeń znajdujących się w nawiasach klamrowych. Do dyspozycji mamy:

  • Rozwinięcie listy: {element1,element2,elementN}
  • Rozwinięcie sekwencji znaków lub liczb: {START..STOP}
  • Dołączanie przedrostka i/lub przyrostka do rozwijanych elementów: przedrostek{foo,bar}przyrostek
  • Powyższe można łączyć ze sobą

Oto kilka przykładów działania brace expansion:

$ echo {foo,bar,baz}
foo bar baz
$ echo {1..10}
1 2 3 4 5 6 7 8 9 10
$ echo {10..1}
10 9 8 7 6 5 4 3 2 1
$ echo {a..z}
a b c d e f g h i j k l m n o p q r s t u v w x y z
$ echo {z..a}
z y x w v u t s r q p o n m l k j i h g f e d c b a
$ echo kot_{1..3}
kot_1 kot_2 kot_3
$ echo {biały,czarny}_kot
biały_kot czarny_kot
$ echo foo_{1,2}_bar
foo_1_bar foo_2_bar
$ echo {{a..z},{A..Z}}
a b c d e f g h i j k l m n o p q r s t u v w x y z A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
$ echo {A..C}{0..3}
A0 A1 A2 A3 B0 B1 B2 B3 C0 C1 C2 C3

W bashu 4.0 wprowadzono jeszcze dwa ułatwienie, uzupełnianie o wiodące zera i określenie skoku inkrementacji sekewncji

$ echo {01..10}
01 02 03 04 05 06 07 08 09 10
$ echo {1..10..2}
1 3 5 7 9
$ echo {a..z}
a c e g i k m o q s u w y

Brace expansion w praktyce

Wszystko pięknie, ładnie, rozwija i wypisuje, OK. Ale do czego to się może przydać? Jak niby ma to pomóc w codziennej pracy? Na przykład w sytuacjach takich jak poniżej.

Najczęściej pojawiającym się przykładem jest tworzenie za jednym razem całej struktury katalogów:

$ mkdir -p ~/projekty/nowy-projekt/{trunk,tags,branches}
$ mkdir -p zdjęcia/{rodzina,zwierzaki/{koty,psy}}

Kasowanie wielu plików na raz:

$ rm picture_{1..100}.jpg
$ rm /bardzo/długa/ścieżka/której/nie/chce/nam/się/pisać/{plik1,plik2,plik3}

Wylistowanie tylko plików z wybranymi rozszerzeniami:

$ ls *.{png,jpg,gif}

Pobranie archiwum podzielonego na kilka części:

$ wget http://example.com/download/plik.r0{1..5}

Tworzenie kopii pliku, lub zmiana nazwy:

$ mv ~/.bashrc{,.bak}
$ cp ~/.bashrc{,.bak}

By później sprawdzić jakie dokładnie wprowadziliśmy zmiany:

$ diff ~/.bashrc{.bak,}

Prawda, że proste?

16:17, kosciak1 , Linux
Link Komentarze (1) »
czwartek, 22 kwietnia 2010

Jedną z ważniejszych czynności jaką należy wykonać podczas konfiguracji edytora tekstu jest wybór odpowiedniego schematu kolorów. Dobrze dobrane kolory sprawiają, że praca nad kodem to czysta przyjemność, wszystko widać jak na dłoni, nie musimy domyślać się co jest czym. Natomiast niewłaściwe kolory to najprostsza droga do piekących oczu, bólu głowy i narastającej frustracji. Dlatego dzisiaj kilka słów o doborze schematu kolorów w vimie.

Galeria schematów kolorów

vimcolorschemetest

Domyślnie w vimie dostępnych jest kilkanaście schematów kolorów, zarówno tych jasnych, jak i ciemnych. Jeśli ktoś nie ma jakichś szczególnych wymagań powinien wybrać z tego coś dla siebie. Jeśli natomiast domyślne schematy to mało zawsze można poszukać czegoś nowego. Na stronie vim.org w dziale scripts znaleźć można ponad 400 schematów kolorów. Sporo.

By oszczędzić sobie ręcznego ściągania i testowania kolejnych schematów można skorzystać z vimcolorschemetest. Jest to galeria zawierająca wygenerowane zrzuty 428 schematów kolorów. Można przeglądać jak w danym schemacie wygląda kolorowanie kodu w językach HTML, Java, C, Perl i LaTeX. Dla ułatwienia rozdzielono schematy jasne i ciemne. Strony galerii są bardzo duże i potrafią sprawić problemy

Gdy już wybierzemy coś dla siebie wystarczy wrzucić ściągnięty schemat do katalogu ~/.vim/colors i ustawić go za pomocą :colorscheme nazwa

CSApprox

Jeśli ktoś używa gvima nie powinien mieć żadnych problemów. Natomiast jeśli ktoś woli vima w konsoli... to pewnie już się przekonał, że coś jest nie tak przeglądając domyślne schematy. Niestety większość schematów kolorów jest pisana z myślą o środowisku graficznym, a jeśli nawet są ustawione kolory dla środowiska konsolowego to raczej nie wykorzystują dostępnej palety 256 kolorów. Kolory wyglądają źle lub bardzo źle...

Rozwiązaniem problemu jest plugin CSApprox, który całkiem sprawnie znajduje odpowiedniki kolorów kolorów, by schematy na konsoli wyglądały podobnie jak w gvimie. Wystarczy ściągnąć paczkę i rozpakować w katalogu ~/.vim oraz zgodnie z instrukcją dodać dokumentację. Poniżej kilka przykładów CSApprox w akcji - po lewej gvim, po prawej na zmianę vim w 8 kolorach, 256 kolorach oraz 256 kolorach z użyciem CSApprox.

vim vs gvim - evening colorscheme
Schemat evening - w 8 kolorach nie jest tak źle, w 256 wygląda już bardzo źle.

vim vs gvim - darkblue colorscheme
Schemat darkblue - nie wygląda w konsoli źle, choć pewno nie jest ciemnoniebieski, z CSApprox trochę lepiej, ale szału nie ma.

vim vs gvim - desert colorscheme
Schemat desert - bardzo przyjemny, miły dla oka, ciemny schemat. Bez CSApprox w konsoli jest zupełnie nie do użytku.

vim vs gvim - default colorscheme

Schemat defaultowy - w przeciwieństwie do wcześniejszych najlepiej wygląda w konsoli z 256 kolorami. W gvimie kolory wydają się zbyt intensywne.

22:09, kosciak1 , Linux
Link Dodaj komentarz »
wtorek, 13 kwietnia 2010

Zauważyłem, że ostatnio coraz więcej czasu spędzam pracując w konsoli. Niewątpliwie jest to jeden ze skutków ubocznych poznawania Vima, który z każdym dniem coraz bardziej mi się podoba. Podczas prac nad jego konfiguracją natknąłem się na problem ilości dostępnych kolorów dostępnych. Polecenie tput colors zwracało 8, mimo że zarówno gnome-terminal jak i xterm potrafią wyświetlić 256 kolorów (co można sprawdzić uruchamiając skrypt colortest.pl). Przy okazji rozwiązywania tego problemu zająłem się "kolorowaniem" kilku narzędzi.

bash

bash - 256 kolorów

Pierwszą rzeczą jaką musimy zrobić to pobranie paczki ncurses-term - zawiera ona między innymi definicję terminalu xterm-256colors, którą zamierzamy ustawić. Teraz pora na edycję ~/.bashrc i ustawienie zmiennej $TERM, wystarczy dopisać następujący fragment:

if [ -e /usr/share/terminfo/x/xterm-256color ]; then
    export TERM='xterm-256color'
else
    export TERM='xterm-color'
fi

Przy kolejnym uruchomieniu konsoli powita nas kolorowy znak zachęty. Jeśli nie podobają nam się jego domyślne ustawienia możemy je zmienić ustawiając zmienną $PS1

ls, grep

Tu sprawa jest dosyć prosta, wystarczy uruchomić ls lub grep z --color=auto (auto, by nie było problemu z zapisaniem wyniku ls do pliku). Najprościej ustawić w ~/.bashrc odpowiednie aliasy:

alias ls='ls --color=auto'
alias grep='grep --color=auto'

Jednak problem pojawia się, gdy chcemy użyć jakiegoś pagera (more, less, czy też most). Podobnie jak w przypadku zapisu wyniku polecenia do pliku, tak i przy użyciu potoku (z ang. pipeline) znaki sterujące kolorami nie są wysyłane. Musimy użyć --colors a w przypadku użycia less dodatkowo wywołać go z -r, na przykład:

ls -al | less -r

Pagery more i most w domyślnych ustawieniach nie mają problemu z kolorami.

diff

colordiff

Kolejnym narzędziem proszącym się o kolory jest diff. Z pomocą przychodzi colordiff - skrypt koloryzujący wynik pracy diff. Jest on dostępny w repozytorium Ubuntu. Teraz wystarczy w ~/.bashrc ustawić alias diff='colordiff' i od razu robi się o wiele czytelniej.

W przypadku Subversion konieczna będzie jeszcze zmiana w ~/.subversion/config i ustawienie właściwego narzędzia do wyświetalania różnic między wersjami.

man

Kolorowy man

Na koniec jak pokolorować pliki pomocy. Jednym z rozwiązań jest użycie most do wyświetlania dokumentacji. Wystarczy ustawić zmienną $MANPAGER='/usr/bin/most' lub uruchamiać man w następujący sposób:

man --pager=most [temat] 

Niestety most nie wykorzystuje skrótów klawiaturowych Vima. Dlatego zdecydowałem się na drugie rozwiązanie, polegające na dodaniu do ~/.bashrc następujących linii:

export LESS_TERMCAP_mb=$'\E[01;31m'       # begin blinking
export LESS_TERMCAP_md=$'\E[01;38;5;74m'  # begin bold
export LESS_TERMCAP_me=$'\E[0m'           # end mode
export LESS_TERMCAP_se=$'\E[0m'           # end standout-mode
export LESS_TERMCAP_so=$'\E[33;01;44m'    # begin standout-mode - info box
export LESS_TERMCAP_ue=$'\E[0m'           # end underline
export LESS_TERMCAP_us=$'\E[04;38;5;146m' # begin underline

Kolory oczywiście można sobie dowolnie pozmieniać. By zrozumieć o co chodzi z tym całym \E[...m można zerknąć na przykład tutaj.

czwartek, 12 listopada 2009

Jak co pół roku, przy okazji premiery nowych wydań Ubuntu, w blogosferze i mikroblogosferze, na krótką chwilę, tematem numer jeden stają się Ubuntu i systemy linuksowe. Pojawiają się relacje z instalacji najnowszej wersji Ubuntu lub aktualizacji wersji poprzedniej, tym żywsze, im bardziej kontrowersyjne zmiany wprowadzono i im więcej problemów się pojawia. Nie mogło być inaczej przy okazji wydania Ubuntu 9.10, w końcu to obecnie jedna z najpopularniejszych dystrybucji Linuksa. Nie brak też pytań, czy nowe Ubuntu jest już systemem operacyjnym dla zwykłego użytkownika. A może żaden linux nigdy takim systemem nie będzie?

Rodowód Linuksa

Na początku trzeba cofnąć się w czasie i zdać sobie sprawę z rodowodu Linuksa. O ile Windows powstawał jako graficzna nakładka na DOS (system stosunkowo prosty, jednoużytkownikowy, jednozadaniowy) i z założenia miał być systemem dla komputerów osobistych, tak w przypadku Linuxa, wywodzącego się z systemów uniksowych, wyglądało to zupełnie inaczej. Unix od początku był systemem wielozadaniowym, wieloużytkownikowym, stawiającym na bezpieczeństwo i stabilność, silnie związanym z rozwojem internetu, przeznaczonym raczej dla serwerów i stacji roboczych. Właśnie ta różnica w założeniach ma fundamentalne wręcz znaczenie. Nie zapominajmy też kto (i dla kogo) tworzył Linuksa. Chyba bardzo nie przesadzę jeśli powiem, że jest to system tworzony przez programistów, administratorów, hakerów i geeków tworzony dla programistów, administratorów, hakerów i geeków.

Wolność, otwartość i możliwość wyboru

Nie bez znaczenia jest filozofia stojąca za Linuksem, który jest wolny, otwarty i daje wybór. Jednak zwykły użytkownik po prostu chce by system operacyjny, oprogramowanie działało i tyle. A o żadnych filozofiach słuchać nie chce. Otwartość źródeł? Dobre sobie... nawet gdyby chciał grzebać w źródłach (a grzebanie w źródłach to ostatnia rzecz jakiej by chciał) i tak nie ma dość wiedzy i umiejętności. Wolność? No niby fajnie, że jest za darmo ale po co dorabiać do tego ideologię? Wybór? Ale po co zwykłemu użytkownikowi wybór?

Prawda jest taka, że zwykły użytkownik nie lubi i nie chce wybierać. Jak ma podjąć decyzję skoro nie ma dostatecznej wiedzy na temat oferowanych alternatyw. A po co ma poświęcać swój czas i energię na ich poznanie, skoro on tylko chce wykonać jakieś proste zadanie. Tak na prawdę te całe internety i komputery nic a nic go nie obchodzą. Zwykły użytkownik nie czuje potrzeby dokonywania zmian, możliwość zmienienia tapety zupełnie mu wystarcza. W Windowsie wszystko jest proste - jedna powłoka systemu, jedno środowisko graficzne, jeden menadżer okien, jeden menadżer plików, jeden pulpit, jedna przeglądarka... W zasadzie wszystko jest pojedyncze. A w przypadku wszelkich pytań systemu wystarczy kliknąć "Tak", "Dalej", "OK". A w Linuksie osobę, która nie ma pojęcia (i nie chce mieć, bo go to zupełnie nie obchodzi) zmusza się do ciągłego podejmowania decyzji, czytania i odpowiadania na setki pytań. W dodatku wmawia mu się, że to dla jego dobra i wygody.

Możliwości systemów *nixowych

Owszem, możliwości systemów unixo-podobnych są imponujące. Jednak , nie ma się co czarować. Zwykłego użytkownika większość z nich zupełnie nie obchodzi i nie dotyczy. Niech mi ktoś powie czy zwykły użytkownik kiedykolwiek:

  • Postanowi w sposób zaawansowany zarządzać zadaniami w czasie wykorzystując narzędzia typu cron, czy też anacron?
  • Wykorzysta możliwość pisania rozbudowanych skryptów z użyciem języka powłoki systemu?
  • Postanowi zautomatyzować najczęściej wykonywane czynności?
  • Wykorzysta możliwość łatwego łączenia różnych narzędzi, programów i skryptów pisanych w różnych językach programowania?
  • Postanowi wyszukać coś w pliku tekstowym z użyciem wyrażeń regularnych?
  • Potrzebuje wyspecjalizowanych narzędzi do monitorowania, przeglądania, analizowania logów i wyciągania z nich określonych danych?
  • Postanowi pracować zdalnie na komputerze?
  • Wykorzysta rozbudowane możliwości ustalania poziomów bezpieczeństwa dla folderów, plików i plików wykonywalnych?
  • Zamierza udostępniać różne usługi wielu użytkownikom systemu?
  • Postawi serwer www, poczty, grup dyskusyjnych, subversion... jakikolwiek serwer?
  • Potrzebuje systemu działającego stabilnie 24 godziny na dobę przez 7 dni w tygodniu?
  • Postanowi pracować w konsoli ze względu na wygodę i szybkość?
  • Lub też całkowicie zrezygnuje z pracy w trybie graficznym?

Powiem krótko: NIE! Dla zwykłego użytkownika to wszystko jest zupełną abstrakcją.

Potrzeby zwykłego użytkownika

Zwykły użytkownik chce przejrzeć pocztę, pogadać przez GG, wejść na Naszą Klasę, pograć na Kurniku, pogadać przez Skype, obejrzeć film i posłuchać muzyki. Tak po prostu. Bez kombinowania i szukania. Bez zastanawiania się czy dana biblioteka jest dostatecznie wolna i otwarta. Bez zaprzątania sobie głowy czy dany program jest napisany w GTK+, Qt, FLTK, Tk, wxWidget, SWT, Swing, czy czymkolwiek innym i jak to będzie wyglądać w danym środowisku graficznym. Ma po prostu działać. Zwykły użytkownik chce do swojego komputera podłączyć słuchawkę do Skype'a, klawiaturę z klawiszami multimedialnymi, aparat fotograficzny, komórkę, drukarkę, czy urządzenie wielozadaniowe. I nic go nie obchodzą jakieś tłumaczenia o zamkniętych sterownikach pisanych tylko dla Windowsa, czy sugerowanie by przed zakupem sprawdzić wsparcie dla danego urządzenia. Zwykły użytkownik uznaje za oczywiste hibernowanie i usypianie systemu na laptopie oraz system oszczędzania baterii i nie zrozumie żadnych tłumaczeń jeśli funkcje te nie działają. Zwykły użytkownik chce bez problemów otworzyć i przeczytać ściągnięty dokument i ma w du^H^Hgdzieś kwestie standardów, otwartych i wolnych formatów, czy panującego windowsocentryzmu.

Niestety, potrzeby zwykłego użytkownika są zupełnie inne (a czasem nawet stoją w  sprzeczności) z potrzebami dotychczasowych użytkowników Linuksa - programistów, administratorów, hackerów i geeków. W końcu kto o zdrowych zmysłach podłączałby słuchawkę dla Skype do serwera? Na co komu flashowe gry w tekstowej przeglądarce internetowej?

Ubuntu - bliskie ideału?

Wróćmy do wspomnianego na początku Ubuntu. Z wydania na wydanie coraz bardziej zbliża się do tego co można by nazwać systemem dla zwykłego użytkownika. Banalnie prosta instalacja (według mnie łatwiejsza niż instalacja takiego Windowsa XP, ale w sumie który zwykły użytkownik samodzielnie instaluje sobie system operacyjny?), mnóstwo kreatorów, podpowiadaczy... Prawie wszystko można wyklikać w trybie graficznym i nie trzeba włączać znienawidzonej przez zwykłego użytkownika konsoli. W dodatku, w przeciwieństwie do Windowsa, system jest już gotowy do pracy i ma prawie wszystkie potrzebne w normalnej pracy programy, a jeśli nie ma wystarczy kilka klików by je zainstalować. Podłączenie drukarki, skanera, kamery, słuchawki nie wymaga instalowania kilkuset megabajtów sterowników i śmieciowego oprogramowania. System działa stabilnie i z czasem nie puchnie "sam z siebie". System prawie idealny. Pod jednym, jedynym warunkiem...

Nie mogą się pojawić żadne problemy. Nie ma tu zupełnie znaczenia czy to problem ze sprzętem, systemem, niezgodnością pakietów, złą konfiguracją. Czy to problem zawiniony przez użytkownika czy nie. Rozwiązanie problemu wymaga wiedzy i umiejętności, a początkujący użytkownik Linuksa najczęściej nawet nie będzie w stanie nazwać problemu. Nawet jeśli jest osobą "techniczną", a nie zwykłym użytkownikiem (patrz ostatnie "przygody" Pawła Wimmera z Ubuntu i Mandrivą). Nawet jeśli rozwiązanie problemu można łatwo odnaleźć na forach i blogach najczęściej wymaga wykonania kilku "magicznych sztuczek" w konsoli czy edycji różnych systemowych plików. A równie dobrze jedyne co uda się znaleźć to raporty błędów, które od lat pozostały nienaprawione.

Oczywiście pracując na Windowsie użytkownik również narażony jest na różne problemy. Wirusy, trojany, konflikty sprzętu, spowolnienie systemu z powodu śmieciowego oprogramowania, nagłe zawieszenia się systemu. Też czasem trzeba coś ustawić w rejestrze systemowym, uruchomić z linii poleceń. Jednak zwykły użytkownik zawsze znajdzie w swojej rodzinie, czy wśród znajomych kogoś, kto mu pomoże rozwiązać problem. W przypadku Linuksa na taką pomoc zazwyczaj nie ma co liczyć. Zrażony pierwszymi niepowodzeniami zwykły użytkownik zrobi to, co zawsze robił w takich sytuacjach - poprosi kogoś o sformatowanie dysku i przeinstalowanie systemu. Tym razem znanego mu już Windowsa.

Podsumowując

Sam jestem dowodem na to, że Linux z powodzeniem może stać się podstawowym systemem operacyjnym, który poradzi sobie ze zdecydowaną większością codziennych (i niecodziennych) zadań. Ubuntu na desktopie sprawuje się znakomicie i czasem potrafi rozleniwić jeszcze bardziej niż Windows. Trzeba się naprawdę postarać by coś popsuć. Każdy, kto ma głowę na karku i choć odrobinę chęci by nauczyć się czegoś nowego, poradzi sobie bez większych problemów. Jednak zwykłemu użytkownikowi - osobie, która nie rozumie komputera i odrobinę się go nawet boi, Linuksa nigdy bym nie polecił. To nadal nie jest system dla niego. Cóż, Linux (a przynajmniej niektóre dystrybucje) dopiero od niedawna stara się stać systemem dla zwykłego użytkownika i obawiam się, że jeszcze długo (o ile w ogóle) to się nie uda. I żadne zaklinanie rzeczywistości niczego nie zmieni.

 
1 , 2
Spis Treści
Kanały RSS
Add to Google
Add to Netvibes