Na Linux-e nemusíme mať vždy dostupné UI, ktoré by nám umožňovalo vykonať niektoré akcie. Avšak po chvíľke používania Linux-u si odvykneš niektoré veci robiť cez UI, pretože ich budeš vedieť rýchlejšie spraviť cez terminál. Tu je zopár základných príkazov, ktoré ja pravidelne volám cez terminál.
Článok je dostupný aj vo forme videa:
Keď si Linux nainstaľuješ, tak je dosť možné, že ti niečo nebude fungovať tak, ako by malo. Chvíľku pogoogliš a nájdeš riešenie tvojho problému vo forme príkazu, ktorý musíš spustiť v termináli. Skopíruješ, spustíš a čakáš, či si si problém opravil/a, alebo či si si vytvoril nový, horší problém.
U mňa sú to napr. tieto dva príkazy. Prvý mi prepne počítač do performance módu a druhý príkaz nastaví rozsah farieb na monitore tak, aby som dokonca videl rozdiel medzi bielou a šedou (bez neho všetko vyzerá divne):
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
xrandr --output DP-1 --set "Broadcast RGB" "Limited 16:235"
Thread, ktorý spomína druhý príkaz
Po inštalácii budeš chcieť inštalovať nejaké programy. Pustíš sa do googlenia a opäť (väčšinou) nájdeš iba nejaké príkazy, ktoré treba spúštať cez terminál.
sudo apt install [PROGRAM]
e.g.:
sudo apt install firefox
sudo apt update
sudo apt upgrade
sudo snap install firefox
Niekedy je spustenie programu cez terminál rýchlejšie, ako spustenie cez UI. Napr. keď chceme programu rovno poslať nejaký parameter. Ja takýmto spôsobom otváram IDE-čka. Niekedy je totiž rýchlejšie sa odnavigovať do zložky cez terminál a rovno si túto otvoriť v IDE-čku:
code .
nautilus .
intellij-idea-comunity .
pycharm-community .
Nie vždy máš po ruke IDE-čko, aby za teba skompilovalo tvoj kód. Vtedy sa ti v niektorých jazykoch zíde terminál.
gcc main.c -o main.o
ghc main.hs -o main.o
Okrem kompilovania cez terminál vieme naše programi v termináli aj spustiť. Prečo by som to robil/a, keď mám moje fantastické IDE? Napr. preto, že moje fantastické IDE spapá 4GB RAM-ky, ktorú môžem chcieť využiť nejakým lepším spôsobom.
./main.o
python main.py
Gradle
./gradlew bootRun
Maven
./mvnw spring-boot:run
dotnet run
Niektoré package managers (napr. gradle, maven, …) fungujú copy/paste spôsobom. Do iných sa pridávaju package práve cez terminál.
Yarn
yarn init
yarn add react
NPM
npm init
npm install react
pip
pip install pytest
Webové alebo iné serverové aplikácie sa väčšinou nasádzajú na nejaký vzdialený server. K tomuto serveru nemáme prístup cez UI, ale iba cez terminál. Na prístup k tomuto terminálu sa používa práve ssh
.
Pripojenie na vzdialený server pomocou ssh kľúča:
ssh -i "~/Downloads/gk-aws-key.pem" [email protected]
Pomocou hesla (heslo si od nás vypýta):
ssh [email protected]
Zobrazí procesy bežiace na danom systéme spolu s ich vyťažením CPU, RAM, …
Keď nemáme prístup k UI textovému editoru, tak si veľmi ľahko poradíme s logmi aj v termináli. Vďaka poslednému príkazu tail
a príkazu grep
terminál dokonca aj preferujem na sledovanie logov. Ale hej, zriedka sa stane, že mi temrinál nestačí a logy si radšej otvorím v UI.
Výpis celého obsahu súboru:
cat logs.txt
Výpis súboru po stranách:
less logs.txt
“Sledovanie” obsahu súboru – výpis sa bude updatovať spolu so súborom:
tail -f logs.txt
grep "error" logs.txt
Alebo aj:
tail -f logs.txt | grep "error"
V termináli/shelli nemáme dostupné bežné textové editory s UI. A tak nám musia postačiť jendoduchšie (urážam práve vim?) editory v termináli.
nano
nano subor.txt
Obsah súboru v nano
uložíš pomocou CTRL+O a nano
zatvoríš pomocou CTRL+X.
vim
vim subor.txt
vim
je téma samo o sebe. Naučiť sa ho vieš napr. pomocou vimtutor.
Na tomto zozname v žiadnom prípade nemôže chýbať git
. Git som využíval aj pomocou UI aj cez terminál a poslednú dobu si Git idem hlavne v termináli. Prečo? Asi zvyk a pomerne rozšírené možnosti. Tu sú základné príkazy, ktoré najčastejšie používam:
git status
git diff
git add subor.txt
git commit -m "Add some changes"
git push origin master
git pull
V poslednej dobe som objavil aj tento krásny príkaz, pomocou ktorého sa dá vytvoriť plnohodnotné PR na GitHub-e. Zatiaľ tomuto príkazu 100% neverím a tak PR-ko vždy checknem aj na GitHub-e, ale veľmi sa mi tento spôsob pozdáva.
gh pr create