CLI, które warto znać: ripgrep, fd, bat i inne perełki z open source

Dlaczego klasyczne CLI przestaje wystarczać

Grep, find, cat, ls – ten zestaw od lat jest fundamentem pracy w terminalu. Działa, jest dostępny na większości systemów, poradniki są pełne przykładów. Problem pojawia się dopiero wtedy, gdy projekt przestaje mieścić się „w głowie”: rosną katalogi, liczba repozytoriów, gałęzi i środowisk. Wtedy każde dodatkowe kilka sekund czekania na wynik grepa albo kombinowanie ze składnią find zaczyna zwyczajnie męczyć.

Nowoczesne narzędzia CLI typu ripgrep (rg), fd, bat, fzf, delta, lsd, zoxide powstały właśnie na tle tej frustracji. Tworzą je osoby, które same od lat żyją w terminalu i bardzo dobrze znają ograniczenia „starej gwardii”. Kluczowy cel: zachować moc i elastyczność klasycznych narzędzi, ale dodać ergonomię, sensowne domyślne ustawienia i znacznie wyższą wydajność.

Stara gwardia kontra nowoczesne narzędzia wiersza poleceń

Klasyczne narzędzia UNIX-owe są niezwykle elastyczne, ale ich projekt powstawał w czasach, gdy skala projektów była zupełnie inna. Dziś programista potrafi mieć jednocześnie kilkanaście dużych repozytoriów, monolityczne monorepo, generowane pliki build, pliki vendor, cache i logi. Tradycyjny grep lub find w takim środowisku szybko zaczynają być zbyt toporne.

Nowoczesne zamienniki celują dokładnie w te problemy:

• ripgrep – działa podobnie jak grep, ale domyślnie respektuje .gitignore, jest wielokrotnie szybszy i wygodniej wyświetla wyniki.
• fd – znacznie prostsza i czytelniejsza alternatywa dla find, również wspierająca .gitignore.
• bat – „kolorowy cat z numerami linii” i podświetlaniem składni.
• fzf – interaktywne wyszukiwanie i filtrowanie w terminalu.
• delta – czytelniejsze, kolorowe porównywanie diffów (szczególnie z gitem).
• lsd – nowoczesny ls z ikonami, lepszym formatem listowania i kolorami.
• zoxide – inteligentna nawigacja po katalogach na bazie statystyk użycia.

Nie chodzi o to, by „porzucić” klasyczne polecenia. Raczej o to, żeby w najczęściej powtarzanych zadaniach sięgnąć po narzędzia, które skracają czas i zmniejszają obciążenie głowy – mniej znaków do wpisania, prostsza składnia, lepsza czytelność wyników.

Skala projektów i rosnąca frustracja

Dopóki projekt ma kilkaset plików, grep i find sprawdzają się zupełnie dobrze. Problem zaczyna się w momencie, gdy:

• monorepo zawiera tysiące modułów i miliony linii kodu,
• w katalogu głównym leżą generowane katalogi build, dist, node_modules, vendor,
• współistnieje kilka języków i frameworków w jednym projekcie,
• każda komenda grep -R trwa kilkanaście sekund zamiast ułamka sekundy.

Do tego dochodzi proza: różne tabulatory, białe znaki, pliki binarne, których wcale nie chcesz przeszukiwać, oraz powtarzalne rzut okiem do pliku, który wolałbyś zobaczyć z podświetleniem składni, a nie jako jednolitą ścianę tekstu.

Nowoczesne narzędzia wiersza poleceń biorą pod uwagę tę rzeczywistość. Standardowo pomijają katalogi typu .git, respektują .gitignore, ignorują pliki binarne, a dodatkowo są pisane w językach takich jak Rust, co daje im sporą przewagę wydajnościową bez skomplikowanej konfiguracji z Twojej strony.

Typowe obawy przed nowymi narzędziami

Bardzo częsta reakcja: „kolejny tool do nauki, a i tak umiem grepa i find”. Tu warto zdjąć sobie trochę presji. Nie chodzi o całkowite przepisanie workflow, tylko o stopniowe dodawanie ulepszeń, które przynoszą natychmiastową, odczuwalną korzyść.

Najczęstsze wątpliwości wyglądają tak:

• Czy muszę uczyć się nowej składni od zera? – ripgrep i fd są bardzo blisko grepa i find, a podstawy mieszczą się w kilku komendach.
• Czy to zadziała na moim systemie? – większość nowoczesnych narzędzi CLI jest dostępna na Linux, macOS i Windows (często także w WSL).
• Czy to jest stabilne? – projekty typu ripgrep, fd czy bat są intensywnie używane w społeczności, w tym przez twórców edytorów i IDE.

Dobrą strategią jest wprowadzenie jednego narzędzia naraz i nauczenie się 3–5 najczęściej używanych opcji. Resztę można poznawać przy okazji. Dużo pomagają aliasy i krótkie funkcje shell, które „opakowują” nowe polecenia tak, by przypominały stare (np. alias grep='rg -n' albo cat='bat').

Pragmatyczne kryteria: kiedy modernizować swoje CLI

Nowoczesne narzędzia CLI nie są celem samym w sobie. Mają wygrywać tam, gdzie liczy się:

• czas – wyraźnie szybsze wyszukiwanie w dużym drzewie kodu,
• czytelność – kolor, numeracja linii, lepszy format wyników,
• ergonomia – prosta składnia i sensowne domyślne ustawienia.

Jeżeli regularnie łapiesz się na tym, że:

• piszesz długie, skomplikowane wyrażenia find i za każdym razem je googlujesz,
• czekasz kilka sekund na wynik grepa w monorepo,
• przeglądasz diffy gita i męczysz się z odróżnianiem zmian,
• spędzasz dużo czasu w terminalu i wolisz nie przerzucać się co chwilę do edytora tylko po to, żeby „rzucić okiem” na plik,

to znak, że nowoczesne narzędzia wiersza poleceń naprawdę mają sens. Wprowadzane stopniowo, po jednym czy dwóch narzędziach, pozwalają skrócić czynności wykonywane dziesiątki razy dziennie.

Jak przygotować środowisko pod nowoczesne narzędzia CLI

Żeby nowoczesne narzędzia CLI naprawdę „zaskoczyły”, dobrze jest poświęcić chwilę na uporządkowanie środowiska. Nie musi to być wielka rewolucja – często wystarczy kilka przemyślanych ustawień, wybór menedżera pakietów i kilka aliasów.

Shell: bash, zsh, fish, PowerShell – co ma znaczenie

Najważniejsze narzędzia z tego zestawu działają w każdym popularnym shellu: bash, zsh, fish, PowerShell, a także w środowiskach typu WSL na Windows. Różnice pojawiają się przede wszystkim w:

• składni aliasów i funkcji,
• pliku konfiguracyjnym (np. .bashrc, .zshrc, config.fish),
• obsłudze completion (auto-uzupełniania) i promptu (np. oh-my-zsh, starship).

Jeżeli korzystasz z basha lub zsh, praktycznie wszystkie przykłady aliasów i funkcji zadziałają „od kopa”. W fish trzeba je lekko dostosować, ale filozofia pozostaje ta sama. W PowerShell można z powodzeniem korzystać z ripgrep, fd czy bat, a aliasy definiować w profilu PowerShella.

Najprostsza rada: nie zmieniaj shella tylko po to, by używać nowoczesnych narzędzi CLI. Zamiast tego zrób mały przegląd swoich konfiguracji i dodaj do nich kilka prostych usprawnień.

Menedżery pakietów: skąd brać narzędzia open source

Nowoczesne CLI praktycznie zawsze są dostępne w standardowych menedżerach pakietów. Zależnie od systemu, najczęściej sięga się po:

• Debian / Ubuntu / Linux Mint – apt
• Fedora – dnf
• Arch / Manjaro – pacman, ewentualnie AUR
• macOS – Homebrew (brew)
• Windows – scoop, chocolatey lub instalacja binarek, plus WSL
• Rust – cargo (część narzędzi jest publikowana jako crate’y)

Przykładowe instalacje:

# Debian/Ubuntu
sudo apt install ripgrep fd-find bat

# macOS (Homebrew)
brew install ripgrep fd bat fzf git-delta lsd zoxide

# Windows (scoop)
scoop install ripgrep fd bat fzf git-delta lsd zoxide

Niektóre dystrybucje zmieniają nazwy binarek (np. fd-find instalowane jako fdfind). W takiej sytuacji wystarczy prosty alias, np. alias fd='fdfind'.

Porządek w dotfiles i konfiguracjach

Dotfiles to wszelkie pliki konfiguracyjne, które zaczynają się od kropki, np. ~/.bashrc, ~/.zshrc, ~/.config/nvim/init.vim. Modernizując CLI, dobrze jest mieć kilka zasad:

• Logiczne grupowanie – aliasy i funkcje związane z wyszukiwaniem w jednym miejscu, z git w innym itd.
• Oddzielenie rzeczy „globalnych” od eksperymentów – np. osobny plik ~/.aliases, który łatwo przenieść.
• Wykorzystanie katalogu ~/.config – wiele nowoczesnych narzędzi (bat, fd, zoxide) czyta konfigurację z tego katalogu.

Przykład prostego podziału dla zsh:

# ~/.zshrc
source ~/.aliases
source ~/.functions

# ~/.aliases
alias grep='rg -n'
alias cat='bat'
alias ls='lsd'

# ~/.functions
cproj() { cd ~/Projects/"$1"; }

Przy takim układzie łatwiej kopiować konfigurację między maszynami oraz wersjonować ją w osobnym repozytorium dotfiles.

Alias, funkcje i łagodna krzywa nauki

Najskuteczniejszy sposób, by naprawdę zintegrować nowe CLI z nawykami, to aliasy. Zamiast pamiętać, że chcesz używać rg zamiast grep, możesz powiedzieć shellowi, by każde wywołanie grep tak naprawdę uruchamiało rg z rozsądnymi ustawieniami.

Przykładowe aliasy:

alias grep='rg -n'
alias rgi='rg -i'
alias rgs='rg -S --hidden --glob "!{.git,node_modules,dist,build}"'

alias fd='fd --hidden --exclude .git'
alias fda='fd --hidden'

alias cat='bat --paging=never'
alias batn='bat -n'   # wymuszone numery linii

Funkcje shellowe pozwalają pójść krok dalej i łączyć kilka narzędzi w jedno zachowanie, np. otwieranie interaktywnego wybieraka plików połączonego z edytorem:

cproj() {
  local file
  file=$(fd . ~/Projects | fzf) || return
  ${EDITOR:-nvim} "$file"
}

Takie podejście bardzo łagodzi obawę typu „za dużo nowych komend do nauki”. Na co dzień wywołujesz po prostu cproj, a „pod spodem” pracują fd, fzf i Twój edytor.

Terminal, kolory i czcionki – drobiazgi, które robią różnicę

Aby nowoczesne narzędzia prezentujące kolorowe wyniki (bat, delta, lsd, fzf) wyglądały dobrze, przyda się:

• terminal wspierający 256 kolorów i truecolor (większość współczesnych terminali),
• ustawiona zmienna TERM na wartość typu xterm-256color,
• czcionka monospaced; ligatury (Fira Code, JetBrains Mono) mogą ułatwiać czytanie, ale nie są obowiązkowe.

Kolory można dostosować przez tematy (np. bat ma wbudowane schematy kolorów), a jeśli pracujesz dużo zdalnie (ssh), dobrym pomysłem jest zachowanie możliwie prostego, ale czytelnego schematu kolorów, który wszędzie wygląda podobnie.

ripgrep (rg) – szybkie i sensowne wyszukiwanie w kodzie

ripgrep to jedno z najczęściej chwalonych narzędzi CLI, jeśli chodzi o wyszukiwanie w kodzie. Łączy składnię bardzo zbliżoną do grepa, domyślną obsługę .gitignore oraz dużą szybkość. Dla kogoś, kto przeszukuje repozytorium kilkadziesiąt razy dziennie, przejście na rg potrafi być jednym z najbardziej odczuwalnych usprawnień.

Podstawy użycia ripgrep w codziennej pracy

Podstawowy użytek z ripgrep to wyszukiwanie frazy w bieżącym katalogu i jego podkatalogach:

rg "error"
rg "UserService" src/
rg -i "token expired"

Kilka rzeczy dzieje się tu „magicznie”:

Domyślne zachowanie, które ratuje czas

ripgrep stara się „zrobić dobrze” bez konieczności podawania pięciu przełączników. Standardowo:

• przeszukuje rekurencyjnie całe drzewo katalogów,
• szanuje .gitignore (oraz inne pliki ignore, np. .ignore),
• pomija katalogi typu target, node_modules,.git,
• używa kolorów i podświetlenia dopasowań,
• drukuje numer linii oraz nazwę pliku.

Jeżeli dotąd każde uruchomienie grep -R --color=auto --line-number wymagało chwili zastanowienia, rg upraszcza to do jednego skrótu. A jeśli coś w domyślnym zachowaniu uwiera, da się to szybko „ustawić pod siebie” aliasem lub plikiem konfiguracyjnym.

Filtry po plikach i językach: szybkie zawężanie wyników

ripgrep rozumie pojęcie „języka” i rozszerzeń plików. To ogromna ulga przy dużych repozytoriach, w których mieszają się frontend, backend, konfiguracja i dokumentacja.

# tylko pliki z rozszerzeniem .ts i .tsx
rg "useAuth" -g'*.ts' -g'*.tsx'

# tylko pliki JavaScript
rg "fetchData" --type js

# wykluczenie konkretnego katalogu
rg "password" --glob '!migrations/'

Przykładowo, gdy debugujesz błąd w Reactowym komponencie, zwykle nie chcesz oglądać logów backendu ani plików .json. Przełącznik --type lub filtry globów szybko to „odszumiają” i zostawiają to, czego realnie szukasz.

Warto zajrzeć do listy obsługiwanych typów:

rg --type-list

Jeśli brakuje jakiegoś języka lub projekt ma niestandardowe rozszerzenia, można dodać własne typy w konfiguracji.

Konfiguracja ripgrep: plik ripgreprc i aliasy

Jeżeli łapiesz się na tym, że za każdym razem dopisujesz te same przełączniki (-n, --hidden, --glob), dobrym krokiem jest przeniesienie ich do konfiguracji. ripgrep czyta plik ripgreprc, którego lokalizację można wskazać zmienną RIPGREP_CONFIG_PATH:

export RIPGREP_CONFIG_PATH="$HOME/.config/ripgrep/config"

Przykładowa konfiguracja, która sprawdza się w wielu projektach:

# ~/.config/ripgrep/config
--colors=match:fg:yellow
--colors=line:fg:blue
--colors=path:fg:green

--smart-case
--hidden
--glob=!.git
--glob=!node_modules
--glob=!dist
--glob=!build

Przy takim układzie podstawowe rg "fraza" daje od razu sensownie odfiltrowane wyniki. Alias można uprościć do czegoś bardzo krótkiego:

alias r='rg'
alias ri='rg -i'

Wyszukiwanie z kontekstem i w wielu plikach naraz

Często sama linia z dopasowaniem nie wystarcza – przydaje się kilka linii „przed” i „po”, żeby zrozumieć, w co właściwie trafiliśmy. Do tego służą opcje kontekstu:

# 3 linie przed i po dopasowaniu
rg "validateUser" -C 3

# tylko linie przed
rg "TODO" -B 2

# tylko linie po
rg "panic!" -A 4

Jeżeli szukasz większych fragmentów, w tym bloków wielolinijkowych, ripgrep obsługuje tryb multiline:

rg -U "(?s)BEGIN CONFIG.*END CONFIG"

Flaga -U wyłącza część zabezpieczeń związanych z binarkami, a (?s) w wyrażeniu regularnym pozwala dopasować także znaki nowych linii. To już narzędzie bardziej „chirurgiczne”, ale użyte w odpowiednim momencie potrafi zaoszczędzić otwierania i przewijania dziesiątek plików.

Integracja ripgrep z edytorem i fzf

Największy efekt widać wtedy, gdy ripgrep współpracuje z edytorem lub fzf. Kilka prostych przykładów:

• Neovim/Vim – pluginy typu Telescope, fzf.vim czy ctrlp potrafią używać rg jako silnika wyszukiwania.
• VS Code – rozszerzenia „ripgrep search” lub wbudowane wyszukiwanie, które pod spodem korzysta z rg.
• fzf – przeglądanie wyników wyszukiwania w trybie fuzzy z szybkim skokiem do pliku.

Prosta funkcja łącząca rg i fzf może wyglądać tak:

rgf() {
  rg --line-number --no-heading "$@" |
    fzf --ansi 
        --delimiter : 
        --preview 'bat --style=numbers --color=always --line-range {2}: {1}' 
        --bind 'enter:become(nvim {1} +{2})'
}

Wywołujesz rgf userService, wybierasz interesujące dopasowanie strzałkami, podglądasz fragment pliku w podglądzie z boku, a enter od razu otwiera właściwy plik w edytorze na odpowiedniej linii.

fd – nowoczesny zamiennik find, który nie boli w użyciu

fd to narzędzie, które ma jeden cel: uprościć wyszukiwanie plików i katalogów na tyle, by nie trzeba było za każdym razem zaglądać do dokumentacji. Zamiast skomplikowanej składni find dostajesz prosty interfejs w stylu fd WZORZEC [ŚCIEŻKA].

Proste wyszukiwanie plików bez bólu głowy

Typowy scenariusz: chcesz znaleźć wszystkie pliki z nazwą „config” w katalogu src. Zamiast:

find src -name '*config*'

w fd piszesz po prostu:

fd config src

Domyślnie:

• wzorzec jest traktowany jako wyrażenie regularne,
• wyszukiwanie jest nieczułe na wielkość liter, jeśli używasz małych liter (smart-case),
• szanowane są pliki .gitignore i ignorowane typowe katalogi „śmieciowe”.

Jeżeli wolisz proste dopasowanie substringów, bez regexów, użyj -g lub przełącz na tryb „glob”:

# wszystkie pliki .log
fd -g'*.log'

# pliki zawierające 'user' w nazwie (glob)
fd --glob '*user*'

Praca z katalogami i szybkie nawigowanie

fd świetnie sprawdza się jako „silnik” do szybkiego skakania między katalogami. Prosty przykład: chcesz przejść do katalogu projektu, który w nazwie ma billing:

cd "$(fd billing ~/Projects -td | fzf)"

Przełącznik -t określa typ:

• -tf – tylko pliki (files),
• -td – tylko katalogi (directories),
• -tl – tylko linki symboliczne.

Jeżeli nie chcesz pisać tego za każdym razem, owinięcie w funkcję shellową bardzo przyspiesza nawigację:

cproj() {
  local dir
  dir=$(fd "$1" ~/Projects -td | fzf) || return
  cd "$dir"
}

Filtrowanie po rozszerzeniach, rozmiarze i czasie

Gdy drzewo plików rośnie, samo dopasowanie po nazwie zaczyna być za mało. fd oferuje kilka praktycznych filtrów, które składają się intuicyjnie:

# wszystkie pliki TypeScript
fd -e ts

# pliki z konkretnym rozszerzeniem w danym katalogu
fd -e md docs/

# pliki większe niż 5 MB
fd --size +5M

# pliki zmodyfikowane w ciągu ostatnich 2 dni
fd --changed-within 2d

# pliki starsze niż miesiąc
fd --changed-before 30d

Jeśli w lokalnym katalogu logów chcesz szybko znaleźć te największe lub najświeższe, połączenie fd z ls (albo lsd) i sortowaniem daje całkiem wygodny „pulpit kontrolny”:

fd -e log /var/log 
  | xargs ls -lh 
  | sort -k 5 -h

Integracja z innymi narzędziami: xargs, fzf, git

fd najczęściej używa się jako pierwszego etapu potoku: znajduje pliki, a następne polecenia coś z nimi robią. Kilka realnych przykładów:

# podejrzenie wszystkich plików konfiguracyjnych w repo
fd '(config|settings).(yml|yaml|json)' 
  | xargs bat

# formatowanie tylko plików .go z katalogu pkg/
fd -e go pkg/ 
  | xargs gofmt -w

# przeszukanie tylko plików, które pasują do wzorca
fd -e js src/ 
  | xargs rg "useAuth"

Da się to też pięknie spiąć z gitem, np. do pracy na zmienionych plikach:

# wszystkie zmodyfikowane (tracked) pliki
git diff --name-only 
  | fd '' -f 
  | xargs bat

Taki zestaw pomaga, gdy chcesz np. przejrzeć tylko pliki dotknięte ostatnim commitem, bez przeklikiwania się przez całe repo.

Konfiguracja fd: domyślne opcje i aliasy

Podobnie jak ripgrep, fd można „oswoić” kilkoma domyślnymi ustawieniami. Szukanie w katalogach ukrytych i wykluczanie .git często sprawdzają się lepiej niż surowe domyślne ustawienia:

alias fd='fd --hidden --exclude .git'
alias fdd='fd --hidden --exclude .git -td'
alias fdf='fd --hidden --exclude .git -tf'

Jeżeli lubisz bardziej zaawansowaną personalizację, fd czyta zmienną FD_IGNORE_FILE oraz pliki .fdignore, dzięki czemu możesz precyzyjnie sterować, które katalogi i pliki mają być zawsze pomijane (np. duże katalogi z assetami czy snapshotami testów).

bat – czytelne podglądanie plików zamiast surowego cat

bat to zamiennik cat z kolorowaniem składni, numeracją linii i integracją z git. Przydaje się szczególnie wtedy, gdy często „tylko zerkasz” na pliki z poziomu terminala – logi, konfigurację, fragmenty kodu.

Czytelny podgląd plików z kolorowaniem składni

Najprostsze wywołanie wygląda znajomo:

bat config.yaml
bat src/app.ts
bat README.md

bat automatycznie dobiera język na podstawie rozszerzenia. Jeśli masz plik bez rozszerzenia lub chcesz wymusić konkretny język, użyj -l:

# wymuszenie języka
bat -l json config.sample

# szybki podgląd pliku logów jako tekstu
bat -l txt server.log

Domyślnie bat wyświetla:

• numery linii,
• podział na „ramkę” z nazwą pliku,
• kolorowanie składni zgodne z motywem (np. gruvbox, OneHalf, Dracula).

Jeżeli takie „udziwnienia” początkowo przeszkadzają, można je stopniowo dostosowywać, wyłączając to, czego akurat nie potrzebujesz.

Tryb zgodności z cat: bez paginacji i z prostym stylem

W trybie domyślnym bat zachowuje się trochę jak połączenie cat i less – dla dłuższych plików korzysta z paginacji. Jeśli wolisz zachowanie bardziej zbliżone do klasycznego cat, można ustawić alias:

alias cat='bat --paging=never --style=plain'

Inne przydatne kombinacje:

# podgląd z numerami linii i minimalnym formatowaniem
alias batn='bat --style=numbers'

# pokazywanie końcówek linii i znaków niedrukowalnych
alias batv='bat --show-all'

Jeśli paginacja Ci pasuje, ale wolisz pełną kontrolę nad pagerem, bat potrafi używać less lub innego programu, który wskażesz w PAGER (np. delta przy podglądzie diffów).

Integracja z git: szybki podgląd zmian

bat jest świadomy gita, co oznacza, że potrafi używać informacji o zmianach i statusie plików. Kilka praktycznych trików:

# podgląd tylko zmodyfikowanych plików w repo
git diff --name-only 
  | xargs bat

# podgląd fragmentów zmienionych linii
git diff --name-only 
  | xargs bat --diff

bat oferuje też tryb --diff, w którym wyróżnia dodane i usunięte linie kolorami zbliżonymi do tych, które zna się z gita. To przydatne, gdy chcesz zobaczyć zmiany w kontekście całego pliku, a nie tylko w standardowym formacie diff.

Wybór motywu i konfiguracja bat

Wielu użytkowników na początku odczuwa „zbyt kolorowy” efekt. Zamiast się do tego zmuszać, lepiej dopasować motyw pod swój terminal.

# lista dostępnych motywów
bat --list-themes

# szybki podgląd konkretnego motywu
bat --theme="TwoDark" src/main.rs

Stałą konfigurację można umieścić w pliku:

Plik konfiguracyjny, aliasy i integracja z innymi narzędziami

Jeśli bat zaczyna pojawiać się w Twoim terminalu częściej niż klasyczny cat, dobrze jest przenieść ustawienia z aliasów do stałej konfiguracji. Dzięki temu zachowanie będzie spójne w każdym projekcie i na każdej maszynie.

Plik konfiguracyjny bat (na systemach uniksowych) to zazwyczaj:

• ~/.config/bat/config – główny plik z opcjami,
• ~/.config/bat/themes/ – katalog z własnymi motywami.

Przykładowa zawartość ~/.config/bat/config może wyglądać tak:

--theme="OneHalfDark"
--style="numbers,changes"
--paging=auto
--map-syntax "*.env:INI"
--map-syntax "Jenkinsfile:Groovy"

Od tego momentu nie musisz pamiętać o przełącznikach przy każdym wywołaniu – bat zawsze będzie używał wybranego motywu, stylu i mapowania rozszerzeń.

Dobrze działa też spięcie bat z innymi narzędziami, których i tak używasz:

# integracja z fzf do szybkiego podglądu plików
fzf-bat() {
  fd . -tf --hidden --exclude .git 
    | fzf --preview 'bat --style=numbers --color=always {}'
}

# podgląd logów z kolorowaniem
tailf app.log | bat -l log

Jeżeli boisz się „zepsuć” przyzwyczajenia do cat, da się to rozwiązać stopniowo. Na początek używaj bat tylko tam, gdzie kolorowanie i numerowanie linii faktycznie coś dają – przy logach, konfiguracji i plikach z błędami. Z czasem ręka sama zaczyna sięgać po alias cat wskazujący na bat.

bat jako lepszy podgląd w pipeline’ach

W wielu skryptach i poleceniach „jednorazowych” typowy wzorzec to:

jakieś_polecenie | grep coś | cat

Podmiana cat na bat często brzmi jak zbędny bajer, ale potrafi realnie ułatwić analizę wyników. Kilka prostych patentów:

# podgląd wyników testów z czytelniejszą strukturą
npm test 2>&1 | bat -l log

# podgląd YAML/JSON po przefiltrowaniu jq/yq
yq '.services' docker-compose.yaml | bat -l yaml
jq '.users[] | select(.active == true)' users.json | bat -l json

# kolorowy podgląd wygenerowanych migracji SQL
diesel migration generate add_user_status
cat migrations/*add_user_status*.sql | bat -l sql

W momencie, gdy pipeline zaczyna produkować bardziej złożony tekst niż zwykła lista plików, pokolorowany i ponumerowany output staje się zwyczajnie łatwiejszy do ogarnięcia wzrokiem.

delta – czytelne diffy i przegląd zmian w terminalu

Skoro bat pomaga w czytaniu plików, naturalnym krokiem jest uporządkowanie diffów. delta to narzędzie, które przejmuje wyjście git diff (albo innych diffów) i prezentuje je w bardziej czytelnej, „kodowej” formie z kolorowaniem składni, wyróżnieniem zmian w linii i wygodnym układem.

Instalacja i podpięcie pod gita

Najwygodniej używać delty jako domyślnego „pagera” dla git diff i pokrewnych komend. Przykładowa konfiguracja w ~/.gitconfig:

[core]
  pager = delta

[interactive]
  diffFilter = delta --color-only

[delta]
  navigate = true
  line-numbers = true
  syntax-theme = OneHalfDark

[merge]
  conflictstyle = diff3

Od tej pory każde git diff, git show czy git log -p będzie przechodziło przez deltę, a Ty dostaniesz dwukolumnowy podgląd zmian, wyróżnienie dodanych/usuniętych fragmentów w tekście i numerów linii.

Lepsza nawigacja po zmianach w dużych commitach

Delta potrafi znacząco odchudzić koszt mentalny przeglądania sporych diffów, np. przy code review z poziomu terminala czy analizie większego refaktoringu. Kilka praktycznych komend:

# diff bieżących zmian względem HEAD
git diff

# podgląd konkretnego commita
git show <hash>

# historia zmian wybranego pliku z diffami
git log -p -- path/to/file.rs

Przy włączonej nawigacji (navigate = true) można skakać po sekcjach diffu klawiszami jak w less (n, N, j, k), a kolorowanie składni ułatwia wychwycenie zmian, które naprawdę coś znaczą, zamiast zgadywania, co się zmieniło w morzu zieleni i czerwieni.

Delta świetnie współgra z bat i ripgrepem:

# szukasz użyć danej funkcji w zmianach z ostatniego commita
git show HEAD | rg "processUser" | bat -l diff

# szybki podgląd zmian w plikach, które dotknęły testy
git diff --name-only | rg "test" | xargs git diff -- >(delta)

fzf – interaktywny „silnik wyszukiwania” w terminalu

Kolejna perełka, która spina wiele innych narzędzi, to fzf – fuzzy finder. To małe narzędzie potrafi zamienić niemal dowolny strumień tekstu w interaktywną listę z wyszukiwaniem „na żywo”. W połączeniu z rg, fd, bat czy nawet git robi się z tego bardzo zwinny zestaw.

Najprostsze użycie: wyszukiwanie w historii, plikach i gałęziach

Po instalacji fzf zazwyczaj dostajesz kilka gotowych integracji (zależy od pakietu / menedżera). W powłoce bash/zsh są to m.in.:

• Ctrl+R – interaktywne przeszukiwanie historii poleceń,
• Ctrl+T – wybór plików z bieżącego katalogu (domyślnie z użyciem find lub fd),
• Alt+C – szybkie przechodzenie między katalogami.

Własne „panele” budujesz, podając fzf listę na wejściu:

# wybór pliku do otwarcia w edytorze
fd . -tf | fzf | xargs nvim

# przeskok na wybraną gałąź gita
git branch --all | fzf | sed 's/.* //; s#remotes/[^/]*/##' | xargs git checkout

Jeśli masz wrażenie, że to skomplikowane, spróbuj najpierw prostych rzeczy: wyszukiwanie w historii (Ctrl+R) czy wybór pliku do edycji. Organicznie poczujesz, gdzie interaktywne filtry rzeczywiście przyspieszają pracę.

Połączenie fzf z ripgrepem i fd w praktyce

Największa moc fzf ujawnia się wtedy, gdy łączysz je w jedną funkcję z innymi narzędziami. Przykłady, które wielu osobom zostają w arsenale na stałe:

# wyszukiwanie plików i otwieranie w edytorze
f() {
  local file
  file=$(fd . "${1:-.}" -tf --hidden --exclude .git | fzf) || return
  nvim "$file"
}

# wyszukiwanie treści + wybór wyniku + skok do edytora
rgf() {
  local file line
  read -r file line < < < "$(rg --line-number --no-heading --color=always "$@" 
    | fzf --ansi --delimiter : 
           --preview 'bat --style=numbers --color=always --line-range {2}: {2} {1}' 
           --with-nth 1,2,3 
    | awk -F: '{print $1, $2}')"
  [ -n "$file" ] && nvim "$file" +${line}
}

W pierwszym przypadku fd dostarcza listę plików, a Ty jedynie filtrujesz je w fzf. W drugim – ripgrep odpowiada za znalezienie dopasowań, fzf za wybór konkretnego miejsca, a bat za podgląd kontekstu. Całość zastępuje mały fragment IDE, ale działa w każdym terminalu, także na zdalnym serwerze.

exa/lsd – nowoczesny ls z kolorami i dodatkowymi informacjami

Przesiadka z klasycznego ls na coś wygodniejszego często wydaje się „kosmetyką”, dopóki nie zobaczysz czytelniejszego drzewa katalogów z ikonami, kolorami i sensownym widokiem uprawnień. exa oraz lsd to dwa popularne zamienniki ls, które robią dokładnie to.

Czytelne listowanie plików i katalogów

Najprostszy alias, od którego wiele osób zaczyna, to:

alias ls='exa --group-directories-first --icons'

lub w przypadku lsd:

alias ls='lsd --group-dirs=first --icon=auto'

Dzięki temu katalogi zawsze lądują na górze, a kolorowanie i ikony pomagają od razu zobaczyć, gdzie są pliki binarne, gdzie konfiguracja, a gdzie katalog z zależnościami.

Bardziej rozbudowane warianty, które zastępują typowe ls -la:

# exa
alias ll='exa -lah --group-directories-first --git'

# lsd
alias ll='lsd -lah --group-dirs=first --git'

Przełącznik --git dodaje kolumnę z informacją o statusie pliku w repozytorium, co przyspiesza orientację, które pliki są nowe, zmodyfikowane lub zignorowane.

Tryb drzewa i przegląd struktury projektu

Gdy projekt zaczyna rosnąć, sensowny widok drzewa staje się zbawieniem. Zamiast ręcznie pisać find . -maxdepth ..., wykorzystaj tryb --tree:

# drzewo katalogów do 2 poziomów
exa --tree -L 2

# struktura katalogu src z pominięciem node_modules
exa --tree -L 3 src --ignore-glob='node_modules'

Podgląd takiego drzewa, połączony z kolorowaniem i ikonami, pomaga nowym osobom w zespole szybko złapać strukturę projektu, a Tobie – ogarnąć, gdzie rozlały się kolejne moduły i pakiety.

dust i du-dust – szybkie sprawdzanie, co zjada miejsce

Gdy dysk zaczyna się zapełniać, klasyczne du -sh * bywa mało czytelne i wolne. dust to nowoczesny odpowiednik, który pokazuje zużycie miejsca w formie posortowanego, „półgraficznego” widoku, dzięki czemu o wiele szybciej widać największych „winowajców”.

Szybkie diagnozowanie problemów z miejscem na dysku

Najprostsze użycie:

# zużycie miejsca w bieżącym katalogu
dust

# ograniczenie liczby wyników tylko do największych katalogów
dust -n 20

# analiza konkretnej ścieżki, np. katalogu domowego
dust ~

Dust sortuje katalogi od największego do najmniejszego i pokazuje proporcje w formie prostego „paska”. To wystarcza, żeby w kilka sekund zobaczyć, że np. node_modules w trzech projektach pożarły sporą część partycji.

Dla osób przyzwyczajonych do du istnieje także narzędzie du-dust lub skrypt aliasujący klasyczne polecenie:

alias du='dust'

Jeśli wolisz zacząć delikatniej, używaj dust tylko do większych analiz – np. gdy czyszczenie dysku zaczyna przypominać szukanie igły w stogu siana.

entr – automatyczne odpalanie komend przy zmianie plików

Podczas pracy nad kodem sporo czasu zjada ręczne odpalanie testów, lintów czy buildów po każdej modyfikacji pliku. entr to małe narzędzie, które obserwuje listę plików i odpala wybraną komendę, gdy coś się zmieni.

Najprostsze watchery bez dodatkowych narzędzi

Schemat korzystania z entr jest prosty: podajesz listę plików na wejściu, a następnie komendę, którą chcesz odpalać po zmianie:

# ponowne uruchamianie testów przy każdej zmianie plików .go
fd -e go ./ | entr -r go test ./...

# automatyczny build frontendu przy zmianach w src
fd . src -e ts -e tsx -e css 
  | entr -r npm run build

# formatowanie pliku przy każdym zapisie (pojedynczy plik)
echo main.rs | entr -r rustfmt main.rs

Przełącznik -r (relaunch) sprawia, że entr zabija poprzedni proces i uruchamia nowy, dzięki czemu nie kumulujesz wielu instancji serwera lub testów.

To proste rozwiązanie przydaje się, gdy nie chcesz instalować całego ekosystemu narzędzi typu webpack-dev-server czy nodemon, a mimo to potrzebujesz odświeżania czy odpalania testów przy każdej edycji pliku.

jq i yq – praca z JSON-em i YAML-em w terminalu

Współczesne narzędzia devopsowe i aplikacje chętnie korzystają z JSON-a i YAML-a. Ręczne grzebanie w tych formatach za pomocą samego grep szybko robi się męczące. jq i yq pomagają filtrować, modyfikować i formatować tego typu dane bez wychodzenia z terminala.

Formatowanie i filtrowanie JSON-a za pomocą jq