(This IsN't The F*cking Manual :)))
UNIX
(gyerekek, becsöngettek!!!)
Namármost miről írjak?
Írhatnék arról, hogy miféle szövegszerkesztők állnak rendelkezesünkre
UNIX-os gépen való munkánkhoz. Egy szóval kifejezve: ijesztőek.
Nem rosszak, nagyonis 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... 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!
Na igen.
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 (hálistennek én nem tartozom közéjük...:) !!!
Szóval ezekről inkább később írok.
Na igen... 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éges- kedé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 job-nak, a task túl általános kifejezés, amire én itt gondolok, az inkább a user által végeztetett meló. Minden jobhoz, 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 tovaá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, maga a shell futtatásának is van saját PIDje, és a 'ps aux'-nak is, amivel ezeket megnézhetjük... Ja, kicsit kényelmesebb a saját PID-ek megtekintéséhez a
psvagy
ps xami csak a miénket írja ki, és csak a leglényegesebb adatokra szorítkozik.
Alapvetően egy process futhat elő- és háttérben. Az előtérben azt jelenti, hogy amíg a proggi fut, addig az adott terminált lefoglalja, míg ha háttérben fut, akkor a parancsértelmező elindítja az elindítanivalót, majd szépen ad egy promptot, mi meg csinálhatunk mást...
Na asszem egyszerűbb, ha szokásos bemutatásos demonstrálásomat alkalmazom:
Itt elkezdtünk valamit, jelenesetben 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. Mi ezután nyomtunk egy CRTL+Z-t (^Z):
[1]+ Stopped ftp ftp.nevada.eduA job leállt, de ettől még él, 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
[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 &..naugye...
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
És amint azt többszöri listázással láthatjuk, a file rendesen jön is le, miközben mi mást 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!!!
Mi közben nyugodtan nyithatunk újabb folyamatot is. Amennyiben a letöltés megtörtént, visszaléphetünk abba a jobba az éppen aktuálisból:
fg 1azaz foreground plusz jobszám.
Nem kell két munkára se 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...:))) .
De egy parancsot is átirányíthatunk háttérbe, amennyiben a parancs végére egy '&'-jelet biggyesztünk:
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... Viszont baj van akkor, ha olyan programot akarunk háttérbe rakni, amelyik in- vagy outputot ad/vár... Például
talk root &után hibaüzenet jön:
[1] - Stopped (tty input) talk root &Amennyiben outputról van szó, ami nem számít nekü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 hozzáküldött adatokat. Szóval tegyük fel, hogy van egy programunk, ami rendesen megy, de állandóan írna a terminálra, ami minket nem érdekel. Ekkor:
hülyeprogram >/dev/null &Na, szóval ezt is meg lehet oldani néha... Amennyiben ilyen háttérjobok futnak, nehézkes a 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, ezek szeretnék visszaállítani az előttük uralkodó állapotokat, letörölni az átmeneti file-okat, stb... Ilyenkor tovább brutalizálunk, a BfG itt a jól hangzó
kill -KILL PIDvagy
kill -KILL %jobazonosítónevet viseli. Az igazán jó poén ezzel együtt a saját shellünk lelövése ill. kill -KILL -0 képviseli, ezzel frankón elszállhatunk...
Biza 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:
nohup program &és 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...
Na most már marha okosak vagyunk, álljunk le kicsit, mert annyira nagy már a mellényem, hogy még magammal se vagyok hajlandó szóba állni...