Ebben a pontban azokat az alapvető parancsokat tekintjük át, amelyekkel állományokat tudunk létrehozni, megtekinteni, másolni, és egyéb műveleteket végrehajtani rajtuk.

Egy állomány létrehozására sok - kezdők számára talán túlságosan is sok - megoldás létezik. Létrehozhatjuk egy szövegszerkeszővel (például ed, vi), kétségkívül ez a leggyakoribb és legkézenfekvőbb megoldás. Most viszont néhány "trükkösebb" megoldással kezdünk, melyek egyben segítenek néhány alapvető Unix jellemvonás megismertetésében is. Mindegyik példánkban a "Szép időnk van ma" szöveget próbáljuk meg egy állományba beírni.

Első megoldásunk az echo parancsra épül. Az echo a DOS alatt megszokott módon működik (az eltérésekről majd lesz szó): a parancssorban argumentumként megadott karaktereket tükrözi vissza, alapértelmezés szerint a képernyőre. A fájlba írandó szöveget így az echo paranccsal a képernyőre már kilistázhatjuk. Félsiker... A teljes sikerhez az átirányítás mechanizmusa segíthet minket. Lehetőség van ugyanis arra, hogy tetszőleges Unix parancs bemenetét vagy kimenetét átirányítsuk máshova, például egy fájlba. Esetünkben a >newfile1 megadással a kimenetet, a képernyő helyett a newfile1 nevű fájlba. És íme, készen is vagyunk:

$ echo Szep idonk van ma >newfile1RETURN

(Ne feledkezzünk meg az egyes sorok végén a kocsi-vissza karakter (RETURN vagy ENTER) leütéséről; a továbbiakban ezt nem jelöljük.)

Következő próbálkozásunk a hamarosan részletesebben is ismertetendő cat parancsot használja fel. A cat parancs egy vagy több, argumentumként megnevezett fájl tartalmát listázza ki a képernyőre (például cat prog1.c prog2.c). Első ránézésre ez nem sokat segít rajtunk, hiszen mi nem egy meglévő fájlt akarunk listázni, hanem épp ellenkezőleg, egy még nem létező fájlt akarunk írni - pestiesen szólva "a többi stimmel...".

Minden "jól nevelt" Unix programra igaz azonban, hogy ha nem nevezünk meg állományt, amit be kell olvasnia és fel kell dolgoznia, akkor alapértelmezés szerint (számítástechnikai zsargonnal élve, default értelmezés szerint) a billentyűzetről (standard input) várja a feldolgozandó adatokat. Hasonlóképpen, explicit kimeneti állománynév hiányában a programok a képernyőre (standard output) írnak. Az e konvenció szerint viselkedő programokat szemléletesen szűrőknek (filter) nevezik, a későbbiekben még sok szó esik róluk. Ha tehát a cat parancsot bemeneti fájlnév nélkül hívjuk meg, akkor az általunk kívánt módon, a billentyűzetről bevitt szöveget listázza ki, a kimenetet pedig a már látott módon irányíthatjuk át a kívánt fájlba:

$ cat > newfile2RETURN

Szep idonk van maRETURN

(A RETURN karakter használatán kívül most vigyázzunk arra is, hogy a kívánt szöveg begépelése után a CTRL-D karaktert is leüssük, hiszen ez jelzi a parancsértelmezőnek, hogy nincs több bemeneti adat.)

A fenti két trükk, a szűrési konvenciók létezése és az átirányítás hihetetlenül rugalmassá teszi a Unixot.

Végül utoljára egy szövegszerkesztővel is létrehozunk egy fájlt:

Az ed editorról külön fejezet szól a könyvben, mostani példánk tényleg csak egy rövid szemléltető volt. Az ed-nek megadjuk a létrehozandó fájl nevét, a parancs begépelése (és az itt már külön nem jelölt RETURN leütése után) elindul az editor, és úgynevezett parancsmódban várja a parancsokat. (A kérdőjeles fájlnév azt jelzi, hogy ilyen nevű állomány eddig nem létezett - már létező fájl esetén a fájl méretét írja ki, karakterekben számolva.) Az általunk kiadott parancs az a (append), ennek hatására az ed az úgynevezett beviteli módba kerül, s az ebből való kilépésig mindent, amit gépelünk, változatlan formában az állományba írja. A beviteli módból úgy lehet kilépni, hogy egy sor elején egy önmagában álló . (pont) karaktert írunk be (ez után is kocsi-visszát kell ütni!). Ennek hatására visszakerülünk parancsmódba; ekkor kiadtuk a w (write) parancsot, ez lemezre írja, tehát elmenti a fájl eddig ideiglenes tartalmát (a képernyőre kiírja az elmentett fájl aktuális hosszát), végül a q (quit) paranccsal kilépünk az editorból.

A fájlok megtekintésére, pontosabban a képernyőn történő megjelenítésre a cat parancs szolgál. (A név onnan származik, hogy ha több fájlnevet adunk meg, akkor ezeket a fájlokat egymásután folyamatosan (concatenated) jeleníti meg... - ennyit a parancsnevek memorizálható jelentéséről...)

A cat parancs a paraméterként megnevezett fájlokat, ennek hiányában pedig a standard inputot, azaz a billentyűzetről, pipe-ból (csőből) érkező adatokat listázza ki, folyamatosan, tördelés nélkül. Ez azt jelenti, hogy ha a megjelenítendő állomány nagyobb, mint egy képernyőoldal, akkor a szöveg kiszalad a képernyőről, s csak a listázás-felfüggesztő, illetve újraindító gombbal lehet szabályozni a megjelenítést. (E két funkciónak rendszerint a CTRL-S, illetve a CTRL-Q billentyű felel meg.) A cat parancs ezen hiányosságainak kiküszöbölésére szolgál a pg és a more, róluk részletesebben a minimanuálban esik szó. Számunkra jelenleg legfontosabb parancsuk pg esetében a RETURN, more esetében a szóköz billentyű; ezek hatására egy képernyőoldalnyit lehet előrelapozni.

Gyakran szükséges egy fájlt máshova helyezni az állományrendszerben, erre a UNIX alatt a mv (move) parancsot használhatjuk. A legegyszerűbb esetben egyetlen fájlt helyezünk át, például a már létező newfile1 állományunkat file1 néven akarjuk a továbbiakban elérni:

A fenti példában a mv parancs két paramétert fogad, s az elsőnek megadott fájlt a másodikként megadott névre nevezi át. Ha a "céltárgy" is közönséges fájl, akkor egyszerű átnevezés történik, az eddig newfile névre hallgató állományt ezentúl file1 néven érhetjük el. (Ha file1 előzőleg nem létezett, akkor a mv parancs automatikusan létrehozza, ha már létezett, felülírja.)

Ha a céltárgy katalógus, akkor a mv parancs másképpen működik: az első paraméterben megnevezett fájlt a régi néven, a céltárgyként megadott katalógus alá helyezi. Ez esetben lehetőség van arra is, hogy kettőnél több paramétert adjunk meg a mv parancsnak: ilyenkor az utolsó argumentumot tekinti a rendszer az átnevezés célkatalógusának, s a többi argumentumban megnevezett fájlokat oda helyezi át. Ha például kiadjuk a mv newfile2 newfile3 newdir parancsot (ne felejtsük el, hogy a newdir katalógust előzőleg már létrehoztuk), akkor newfile2 és newfile3 egyaránt bekerül a newdir katalógusba, változatlan néven:

A fájlok másolására a cp (copy) parancs szolgál. Fontos különbség a DOS-hoz szokott felhasználó számára, hogy itt mindenképp legalább két argumentumot meg kell adni, azaz a DOS alatt szokásos copy fájl megadásmód nem megy, a célfájlt vagy katalógust is meg kell adni: az előző DOS példa ekvivalense így a cp fájl . parancs, ahol expliciten megneveztük az aktuális katalógust, mint célkatalógust.

A cp parancs működése hasonló a mv parancshoz, azaz itt is fájlt fájlba másol, ha a céltárgy fájl, illetve katalógusba helyez, ha a céltárgy katalógus.

Fájlokat az rm (remove) paranccsal törölhetünk, természetesen most is megadhatunk több fájlnevet a paraméterlistán. Az rm parancs opciói közül gyakran fontos lehet a -f: ennek hatására az egyébként írásvédett fájlokat is törli az rm. A -i (interactive) opció hatására a rendszer egyenként visszaigazolást kér a fájlok törlése előtt. (Számos rendszerben ugyanez az opció működik a mv és a cp parancsnál is.)

Végül egy igen hatásos, de egyben igen veszélyes opcióról: a -r hatására rekurzív módon törlődik mind a megnevezett katalógus a benne lévő fájlokkal, mind a fájlhierarchiában belőlük származó összes katalógus és állomány.

Ellentétben a DOS-sal, a UNIX-ban a fájlok törlése visszafordíthatatlan folyamat - KITÖRÖLT FÁJLT SEMMILYEN MÓDON NEM LEHET HELYREÁLLÍTANI!!! Éppen emiatt is, egyes parancsértelmezőkben lehetőség van olyan konfigurálásra, hogy törlést, felülírást, és más visszafordíthatatlan műveleteket ne hajtson végre a rendszer, hanem minden esetben kérjen visszaigazolást a "gyanús" műveletekről. E célt szolgálja a fentiekben említett -i opció is.

A UNIX fájlrendszerének egyik jellemző sajátossága a láncolás (linkelés) fogalma, ami a DOS és más egyfelhasználós operációs rendszerek alatt nem található meg. E mechanizmus arra szolgál, hogy egy adott állományt több néven is el lehessen érni az állományrendszerben. Ha például van egy állományunk text néven, akkor az ln parancs segítségével elérhetjük, hogy mondjuk szoveg néven is hivatkozhassunk rá.

A láncolás tényéről az ls -l parancs kimenetét vizsgálva győződhetünk meg: a valamilyen más néven is láncolt állományok láncszáma (link count) egynél nagyobb érték.

Látható, hogy text és szoveg minden paramétere azonos, ugyanakkor láncszámuk egynél nagyobb, s ahogy egyre több láncolást hajtunk rajtuk végre, egyre jobban nő.

A láncolás mibenlétének megértéséhez érdemes egy kicsit részletesebben megismerkedni a UNIX fájlrendszerének belső szerkezetével. A 6. ábra mutatja a UNIX fájlrendszer belső felépítését. Minden UNIX fájlrendszer elején megtalálható az úgynevezett szuperblokk, amelyik a fájlrendszer legfontosabb adatait, a belső táblák és azonosítók méretét, stb. tartalmazza. Ezt követi az úgynevezett inode tábla, végül a ténylegesen felhasználható lemezterület, ahol az állományok által lefoglalt és a még szabad lemezblokkok vegyesen helyezkednek el.

Az inode név az index-node bevett rövidítése, és a fájlrendszer kialakításának fontos tényére utal, nevezetesen arra, hogy az állományok jellemzőit tartalmazó inode-okat indexként használják a rendszerprogramok. Az inode tábla egy fix méretű tábla, fix hosszúságú rekordokkal, s minden egyes fájlhoz, lett légyen az közönséges adatállomány, vagy katalógus, egy és csakis egy inode bejegyzés tartozik. Az inode tartalmazza az adott fájlra vonatkozó összes lényeges információt, az állomány méretét, típusát, tulajdonosát és csoportját, a hozzáférési jogokat, és az állományt alkotó lemezblokkok fizikai elhelyezkedését a lemezen. Egy információ hiányzik csak az inodeból, mégpedig a szóbanforgó állomány neve: ezt az információt a katalógus(fájl) tartalmazza.

A katalógusfájlban minden egyes fájlhoz, ami az adott katalógusban szerepel, egy bejegyzés tartozik. E rekord nem tartalmaz mást, mint az állomány inode számát, és az állomány nevét. Nézzük meg ezek után, mi történik akkor, amikor mondjuk a /users/demo/text fájlt szeretnénk kilistázni? (Segítségképpen olyan formában (a -i [inode] opcióval) listáztuk ki a szóban forgó fájlokat, hogy az inode értéke is szerepeljen az első oszlopban.)

A rendszer először megkeresi a gyökér katalógus inode-ját, ez a második inode (#2). Az inode rekordból kikeresi, hogy a lemezen fizikailag hol helyezkedik el maga a / katalógusfájl, ami a gyökérkatalógusban lévő fájlok nevét adja meg. Megnyitja e katalógust, megkeresi benne a users bejegyzést, megnézi az ahhoz tartozó inode számot (#8194), ezt indexként használva az inode táblában megkeresi a /users katalógusra vonatkozó bejegyzést is. Az ebben az inode-ban tárolt adatok alapján megkeresi a lemezen a /users katalógusfájlt, megnyitja, és megkeresi benne a demo bejegyzést, az ahhoz tartozó inode szám (#20699) alapján az inode táblában megkeresi a megfelelő bejegyzést, kiolvassa belőle a /users/demo katalógusfájl helyét, megnyitja a katalógust, megkeresi benne a text fájlra vonatkozó bejegyzést, a hozzátartozó inode szám (#20816) alapján megkeresi az inode-ot, és annak alapján megnyitja a tényleges fájlt.

Az egész módszernek az a lényege, hogy három szintű az állomány nyilvántartás, az inode-ok, a katalógusfájlok és a tényleges fizikai állományok között oszlik meg az információ, s a katalógusfájlok csak név és inode információt tartalmazzák, az inode-ok pedig minden egyebet. Ennek alapján érthető meg igazán a láncolás mechanizmusa: amikor egy fájlt linkelünk, nem történik más, mint hogy valamelyik katalógusban egy olyan bejegyzést hozunk létre, ami egy már létező, és más néven is hivatkozott inode-ra mutat. Maga a fájl változatlan marad, a láncolás tényét kizárólag az új katalógus bejegyzés, és az inode-ban megnövelt láncszám jelzi.

Felmerülhet a kérdés, mi van akkor, ha egy láncolt fájlt törlünk? A fentiek ismeretében könnyű a válasz: törléskor a rendszer mindig a láncszám vizsgálatával kezd, ha annak értéke egynél nagyobb, akkor csak a fájlnév bejegyzést törli az adott katalógusból, és eggyel csökkenti a láncszámot. Ha a láncszám egy, akkor ténylegesen is törli az állományt, azaz nemcsak az (utolsó) katalógus bejegyzést szünteti meg, hanem az inode táblából is törli a fájlra vonatkozó bejegyzést.

Nem beszéltünk még arról, hogy mire is jó tulajdonképpen a láncolás? Két nagy előnye van, az egyik a névütközések feloldása, a másik a helytakarékosság.

A névütközések problémája onnan ered, hogy a UNIX verziók eltérő fejlődése miatt ugyanolyan néven kezdtek nevezni más-más parancsokat. Legismertebb példa erre az rsh parancs, ami a System V alapú rendszerekben a restricted shell-t jelenti (ez a szokványos Bourne shell egy korlátozott szolgáltatásokkal bíró változata), a BSD alapú UNIX rendszerekben viszont a remote shell rövidítése, ami a távoli gépeken történő parancsvégrehajtásra szolgál. Mivel a mai rendszerekben mind a két parancs szerepel, általában csak a katalógusokban definiált keresési sorrend dönti el, hogy az rsh parancs kiadásakor melyik indul el a kettő közül (mindig a másik, mint amelyiket akartuk, erről saját tapasztalatunk alapján biztosítjuk a Nyájas Olvasót...). Ha viszont valamelyiket egy eltérő névvel láncoljuk, akkor a névütközés problémáját feloldottuk. A restricted shell rendszerint a /usr/bin könyvtárban található, míg a remote shell a /usr/ucb alatt. Adjuk ki az alábbi parancsot (Ehhez superuser jogok kellenek!):

E parancs hatására a továbbiakban remsh néven hívhatjuk a remote shell-t, rsh néven a másikat, s a módszer a katalógusok keresési sorrendjétől függetlenül működni fog.

A linkek mellett szóló másik érv a helytakarékosság. Tegyük fel, hogy van két C nyelvű programunk, amelyek igen hasonló funkciókat látnak el, lényegtelen eltérésekkel. Megtehetjük azt, hogy mindkettőt külön-külön lefordítjuk, keletkezik két éktelen nagy bináris programunk, különböző néven. Ennél sokkal jobb megoldás, ha egy közös, némileg ugyan nagyobb forráskódot fordítunk le egy példányban, a keletkezett bináris végrehajtható program nevét pedig a másik programnévhez láncoljuk. (A program futás közben el tudja dönteni, hogy milyen néven hívták, s az annek megfelelő végrehajtási ágakra futhat.) Látszik, hogy ez esetben csak egy darab nagyméretű program foglal helyet a lemezen, a linkelés helyigénye elhanyagolható (gyakorlatilag a második név katalógus-bejegyzése, ami tipikusan 16 bájt.) A legszebb példa minderre éppen a mv, cp és ln parancs esete. E három program, mint már láttuk, erősen hasonló funkciókat lát el, a paraméterek kiértékelése, számos opció, az inode-okon és a katalógusokon végrehajtandó műveletek nagy része közös, tehát a három program viszonylag jól integrálható. A legtöbb rendszerben ezért egy közös bináris végrehajtható program végzi mindhárom tevékenységet.

Mint a fenti példán is látható, körülbelül 26 kbájt helyet nyertünk, hiszen csak egy példányban létezik a 13 kbájt méretű bináris fájl, s ezen kívül csak a két link 32 bájtja foglal helyet.

Ez az eljárás egyébként nemcsak bináris végrehajtható fájloknál, de shellscript-eknél is alkalmazható.

Még egy dologról említést kell itt tennünk, s ez a szimbolikus lánc (symbolic link) fogalma. A UNIX rendszer kétféle láncolási eljárást ismer, a merev és a lágy láncolást (hard and soft link). Az előbbiekben a merev láncolással foglalkoztunk, ennek legfőbb jellemzője az, hogy a láncolt fájl teljesen egyenértékű az eredetivel, hiszen egyazon inode-ra mutat két egyenértékű katalógus bejegyzés, amelyek között nem lehet különbséget tenni.

A "lágy láncolás", vagyis a szimbolikus link viszonylag késői újítás a UNIX-ban, a SunOS operációs rendszerből terjedt el az elmúlt években, de mára már szabványos eleme a UNIX-nak. Lényege, hogy a szimbolikus link katalógus bejegyzése nem a fájl inode-jára mutat, hanem egy olyan különleges fájlra, ami a láncolt fájl nevét tartalmazza. Szimbolikus linket szintén az ln paranccsal hozunk létre, de a -s opciót is meg kell adni:

Látható, hogy a láncszám ebben az esetben nem változott (az csak a hard link esetén nő), a fájltípusnál egy 'l' betű szerepel, jelezvén, hogy szimbolikus linkről van szó, s a fájlnévnél a '->' karakterek jelzik, hogy melyik fájlhoz van láncolva az állomány.

Ha a példánkban szereplő sendmail.cf fájlt meg akarja nyitni egy prog-
ram, akkor a következő történik: az előzőekben vázolt módon eljut a /users/demo/sendmail.cf fájl inode-jáig; észreveszi, hogy szimbolikus link a fájl típusa; megnyitja a fájlt; kiolvassa a tartalmát, ami jelen esetben /usr/lib/sendmail.cf; a továbbiakban ezt a fájlt keresi és nyitja meg, a már ismert módon.

Mire jó a szimbolikus link? Legfontosabb előnye az, hogy lehetővé teszi különböző fájlrendszerek közti láncolást. Ennek megértéséhez néhány szóval meg kell említeni a UNIX fájlrendszer egy érdekes tulajdonságát, mégpedig a mountolhatóság fogalmát. A UNIX fájlrendszere, ahogy azt a felhasználó szerves egésznek látja, nem feltétlenül egységes fizikai szinten is. Ha például több merevlemez van a gépben, ezeken külön-külön UNIX fájlrendszerek vannak installálva, hasonlóképpen, egy CD-n, vagy egy floppy diszken is. Mountolásnak hívják azt a tevékenységet, amikor egy ilyen különálló fájlrendszert becsatolunk egy már meglévőhöz. A 7.ábrán egy olyan példát mutatunk be, ahol egy floppyn lévő UNIX-os fájlrendszert csatolunk be a gazdagép UNIX fájlrendszerébe, a /mnt katalógus alá. A továbbiakban a floppyn lévő fájlrendszer gyökérkatalógusa a /mnt hivatkozással érhető el, a floppyn lévő /src katalógus /mnt/src néven és így tovább. Magáról a mountolásról több szót nem ejtünk, mert a kérdés leginkább a rendszeradminisztrátorokat érinti, a felhasználó szempontjából a becsatolás észrevehetetlen kell hogy legyen. A fentiek annyiban érdekesek a számunkra, hogy merev láncolást nem lehet két különböző mountolt fájlrendszer között létrehozni. A linkelés mechanizmusa ugyanis arra épül, hogy az inode-ok egy állományrendszeren belül egyértelműen azonosítják a fájlokat, azaz ugyanazon inode-ra történő hivatkozás ugyanazt a fájlt jelenti. Mivel azonban minden egyes önállóan becsatolható fájlrendszerben független a számozás (mindegyikben 2 a root inode stb), az inode érték önmagában nem nyújt elégséges információt arra nézve, hogy a keresett fájl a teljes állományrendszerben hol található. Ezért ha fájlrendszerek közti láncolást próbáltunk meg, az alábbi, vagy hasonló értelmű hibaüzenetet kapunk:

A fenti problémát kikerülhetjük a szimbolikus láncolással, mert a szimbolikus linkben szereplő név akárhova, más állományrendszerbe, nemlétező, vagy pillanatnyilag el nem érhető helyre is mutathat.

A merev láncolás másik hátránya, hogy csak egyedi fájlok linkelését teszi lehetővé, katalógusokét nem. Szimbolikus link alkalmazásával egész katalógusokat láncolhatunk át egy paranccsal egy másik fájlrendszerbe, ami gyakran hasznosnak bizonyulhat, ha például a jobb terhelésszétosztás miatt újra kell strukturálni a fájlrendszert, és egész alkalmazáscsomagokat helyezünk át más fájlrendszerbe, ugyanakkor mindezt a felhasználó számára észrevétlenül akarjuk végrehajtani.

Tartalomjegyzék