(This IsN't The F*cking Manual)
UNIX
a la Hamster
(gyerekek, becsöngettek!!!)
Nem mondhatom el senkinek, nem is mondom hát el senkinek...
... azt, ami az eszembe jutott, mert nem tartozik a tárgyhoz. Inkább beszéljünk másról!
Írhatnék most például arról, hogy miféle szövegszerkesztők állnak rendelkezesünkre UNIX-os gépen való munkánkhoz. Egy szóval körülírva: ijesztőek. Nem rosszak, nagyon is használhatóak, de nem Winwordön nevelkedett embereknek találták ki őket. Sokfajta van, például a vi, a joe, az ed, az ex, emacs, stb (csupa beszédes név!)... Ezek sokban hasonlítanak egymásra, általában van szöveges- és parancsmódjuk, pár tucat billentyűfunkciót fejben kell tartanunk hozzájuk. Regényt, eposzt nem érdemes ezek alatt írni. De programot csak kell, hiszen az egész UNIX erre lett kitalálva! Aki büszke magára, hogy MSDOS alatt c++ban megírt egy strukturált, gusztusos kinézetű programot, az próbálja meg ugyanezt megtenni UNIXban, mondjuk a vi segítségével, és máris becsülni fogja azokat, akik így írnak programot... A nagy különbség egy másmilyen editor és mondjuk a vi között az, hogy a vi használatához nem kell húszmillió gigahertzes processzor. De erről majd később írok, ez most csak a reklám volt, most inkább...
Most inkább jöjjön egy kis mese a UNIX kellemes multitakolhatóságáról (váov, ez majdnem olyan szép szó, mint a megszentségteleníthetetlenségeskedéseitekért...). Itt ugyanis miközben valami csinálok, és az eltart egy darabig, nyugodtan átléphetek egy másik task-ba. A user taskjait nevezzük process-nek, a task túl általános kifejezés, amire én itt gondolok, az inkább a user által végeztetett meló. Minden ilyenhez, illetőleg minden egyes cselekedetünkhez tartozik egy process identifier, azaz PID, amely a folyamat elhalásáig el fogja azt kísérni: ezzel a számmal hivatkozhatunk az adott task-ra a továbbiakban... (Ezeket már láthattuk a 'ps aux' tárgyalásakor is.) Kis visszapörgetés:
USER PID %CPU %MEM SIZE RSS TTY STAT START TIME COMMAND hamster 269 0.0 0.5 376 40 pp0 S 16:40 0:00 -bash hamster 312 1.8 9.8 773 660 pp0 S 16:49 1:14 /usr/ircii-2.8/irc hamster 506 0.0 3.0 80 208 ? R 17:54 0:00 ps auxMint azt láthatjuk, a shell futtatásának is van saját PIDje, de a 'ps aux'-nak is, amivel ezeket megnézhetjük... Egy processnek alapvetően ekét futási állapota lehet: futhat elő- és háttérben. Az előtérben azt jelenti, hogy amíg a program fut, addig az adott terminál I/O kapacitását lefoglalja, míg ha háttérben fut, akkor mi közben csinálhatunk mást is ugyanazon a terminálon. Azt hiszem egyszerűbb, ha szokásos bemutatásos demonstrálásomat alkalmazom:
Elkezdtünk valamit csinálni, jelen esetben egy fájlt letölteni:
ftp> get ALL_new_this_month.gz 200 PORT command successful. 150 Opening BINARY mode data connection for ALL_new_this_month.gz (1661476 bytes).Ez el is kezdődött rendesen. Ezután nyomtunk egy CRTL+Z-t (^Z):
[1]+ Stopped ftp ftp.nevada.eduA job leállt, de nem halt meg, csak várakozik, ahogy ez a jobs című utasítással megtekinthető:
labor:/scratch/hamster$ jobs [1]+ Stopped ftp ftp.nevada.edu labor:/scratch/hamster$ bg 1A bg-vel beraktuk háttérbe a folyamatot.
[1]+ ftp ftp.nevada.edu &A & jel azt jelenti, hogy háttér (background) folyamatról van szó, ami rendesen folyik.
labor:/scratch/hamster$ jobs [1]+ Running ftp ftp.nevada.edu &Mondom folyik:
labor:/scratch/hamster$ dir total 63 drwxr-xr-x 2 hamster users 2048 May 6 10:39 ./ drwxr-xr-x 11 root root 1024 Apr 6 15:07 ../ -rw-r--r-- 1 hamster bin 59904 May 6 10:39 ALL_new_this_month.gz labor:/scratch/hamster$ dir total 105 drwxr-xr-x 2 hamster users 2048 May 6 10:39 ./ drwxr-xr-x 11 root root 1024 Apr 6 15:07 ../ -rw-r--r-- 1 hamster bin 102912 May 6 10:39 ALL_new_this_month.gz labor:/scratch/hamster$ dir total 120 drwxr-xr-x 2 hamster users 2048 May 6 10:39 ./ drwxr-xr-x 11 root root 1024 Apr 6 15:07 ../ -rw-r--r-- 1 hamster bin 118272 May 6 10:39 ALL_new_this_month.gz... mint azt többszöri listázással láthatjuk, a file rendesen jön lefelé, miközben mi mást is csinálhatunk. Sőt! Csinálunk is, mivel a 'dir' parancs (na jó, akkor alias) végrehajtása is másik tasknak számít! Nyugodtan nyithatunk újabb folyamatot is. Amennyiben a letöltés megtörtént, visszaléphetünk a régebbi jobba az éppen aktuálisból:
fg 1azaz "foreground" plusz jobszám. Természetesen nem kell két munkára korlátozódni, annyit nyithatunk, amennyit a rendszer csak elbír (ami azért korlátozva van, mivel a memória is véges, a gépé is, meg a miénk is, szépen elfelejtkezhetünk arról, hogy másik taskban valami mást csináltunk...:-) .
Egy-egy parancsot indításkor is áttehetünk háttérbe, amennyiben a parancs végére a más ismert &-jelet biggyesztjük:
crypt < nagyonhosszúfájl > kódolttxt &Ilyenkor az adott fájl szépen a háttérben "bekódolódik", mi meg ftp-zhetünk nyugodtan kalózprogramokat... Baj akkor van, ha olyan programot akarunk háttérbe rakni, amelyik ki- vagy bemenetet ad/vár... Például a
talk root &után hibaüzenet jön:
[1] - Stopped (tty input) talk root &Amennyiben outputról van szó, amire nincs szükségünk, azt át is lehet irányítani a "fekete lyukba", a /dev/null nevezetű 'berendezésbe'. Ez nem csinál semmit, csak nyomtalanul elnyeli a beleirányított adatokat. Példának okául: tegyük fel, hogy van egy programunk, ami rendesen fut, de állandóan írni akar a terminálra, ami minket nem érdekel. Ekkor így indíthatjuk háttérben futtatva úgy, hogy ne legyen gond a program kimenetével:
hülyeprogram >/dev/null &Amennyiben háttérjobok futnak aktívan, nehézkes a shellből való kilépés. Vagy:
kill megszüntetni_szándékozott_job_PIDjeEz nem feltétlenül fog működni, mivel nem minden program hajlandó csak úgy elszállni, többségük szeretné visszaállítani az előttük uralkodó állapotokat, letörölni az átmeneti file-okat, stb... Ilyenkor tovább brutalizálunk, a BFG9000 itt a jól hangzó
kill -KILL PIDvagy
kill -KILL %jobazonosítónevet viseli. Igazán jó poén a saját shellünk lelövése, melynek legegyszerűbb módja a kill -KILL -0 ,ez rendszergazdaként Igazán nem Jó Ötlet(TM). Az is megeshet, hogy valamiért azt akarjuk, hogy egy program azután is folytassa futását, hogy mi kiléptünk a rendszerből. Ilyenkor a
nohup program_neve &kiadása után már ki is léphetünk, feltéve, hogy az említett proggi nem vár ki- pláne bemenetet, ill. ha ezeket kellően átirányítottuk...