A MagyArch oldalon egy érdekes cikk jelent meg a dot fájlokról. Érdemes elolvasni, mert hasznos lehet és egy fontos témát tárgyal: a rejtett, illetve a rendszerfájlokat. Általában egy asztali felhasználó ritkán találkozik ezekkel, de ha már nagyon picit is haladó vagy, és szeretnéd a Linux rendszeredet ténylegesen testre szabni, azaz nem a kinézetet állítani, és az ikonokat picit odébb tenni, akkor már előkerülnek a konfigurációs fájlok. Ezek a konfigurációs fájlok fontos részei a rendszernek, sok magát a rendszert, vagy egy programot állít be. Ebben nincs semmi újdonság. De a fórumokon és egyéb helyeken többször találkoztam tipikus hibákkal, így picit körbajárjuk a konfigurációs fájlok szerkesztését és azt a rutint, amit én követek. Nem egy adott, konkrét fájlt szerkesztünk, hanem egyfajta alapokat teremtünk ahhoz, hogy rutinszerűen, gyorsan és nagyobb probléma nélkül tudjunk szerkeszteni fájlokat.
Mik is azok a dot fájlok?
„A név az angol “dot”, azaz pont, és a fájl szavakból tevődik össze, azaz egy ponttal kezdődő fájlt vagy egy ponttal kezdődő mappában található fájlt jelöl.” – írja Isti. Így már az elején érdemes megjegyezni: a ponttal jelzett fájlok, könyvtárak rejtettek. Ha nem találod meg őket a fájlkezelőben, akkor be kell állítania a láthatóságokat. Ezt jellemzően ctrl+h kombinációval teheted meg. A krusader-ben alapértelmezetten az alt+. lesz a nyerő. Ha pedig parancssorban az ls parancsot használod az -a kapcsolóval kell kombinálni. Így máris kikerülöd azt az kellemetlen helyzetet, hogy olvasol valamilyen beállításról, és nem találod meg a fájlt. Kissé kellemetlen, ha fórumon reklamálnak, hogy „nekem nincs ilyen fájlom”, ha elsőre nem jelenik meg a fájlkezelőben.
Miért rejtettek ezek a Linux alatt?
Mert – ahogy már volt róla szó – ezek rendszer beállító, vagy program beállító fájlok, azaz config fájlok. Amit nem biztos, hogy látnia kell a nagyon kezdőknek, így elrejtették őket.
Ezért fontos kiemelni, hogy ezeket odafigyelve kell szerkeszteni. Bár ha egy programod beállító, config fájljában valami nagy gubancot csinálsz, és nem indul a program, az kevésbé problémás, de ha egy rendszerbeállítóban rontasz el valamit, akkor az már gond. Ha nem indul a rendszered, akkor sem kell pánikoni, ha legalább egy terminált kapsz, akkor nincs gond, javítani tudod – ha rám hallgatsz és készítettél mentés.
Ha sérülhetnek a beállító fájlok…
… akkor azokat menteni kell. Logikus gondolat. Ezt én háromfelé osztanám. Az első, ami sok Linux rendszerben alapvető, hogy van egy skel mappád, valahol a /etc/skel mappában. Vagy máshol, de ha nem itt van a skel, akkor a disztribúciód leírásában nézd meg, hogy hol találod. Ez tartalmazza az alapértelmezett, azaz az eredeti beállítófájlokat. Így mindig vissza tudsz térni az originál beállításhoz, ha az itt fellelhető config fájllal felülírod a sajátodat. Itt jellemzően csak a felhasználói configok vannak, ami azt jelzi, hogy ha egy egész rendszerre vonatkozó configot írsz át, akkor triplán figyelni kell, mert azokat itt nem találod meg! Azt is érdemes tudni, hogy ez valóban csak egy alap, egy végső menedék. Itt nem feltétlen lesz meg minden program beállító állománya.
A másik fontos tény, hogy bár egy csomó configot a skel-ből vissza tudok állítani, de ez nem pótolja az általam már jól bekonfigurált programot! Ha arra kényszerülsz, hogy a skel-ből állíts vissza, akkor elvész az eddigi munkád. Ami igencsak nem jó érzés. Így érdemes az automata mentési folyamatodba (én a lucky-t használom) beilleszteni azokat a config fájlokat, amiket meg akarsz őrizni. Igen, macera, mert ha komolyabban belenyúlsz egy fájlba, és nem akarod elveszíteni a beállításokat probléma esetén, akkor azt be kell állítani a mentésbe. Ami lehet, hogy fél perc! 🙂
A harmadikként a legfontosabbat említem: mielőtt nekiállsz egy config fájlt szerkeszteni, csinálj róla egy mentést. Nem kell túlzásba vinni, ha nem akarsz napi szinten belenyúlni ilyen fájlokba, akkor elegendő egy cp .configfajlneve .configfajlneve_old is. Így lesz egy mentésed, ha gond van, akkor a szerkesztett és elrontott .configfajlneve törlésre kerül, a configfajlneve_old végéről meg lekerül a _old. Így visszaáll az eredeti rend.
Igen, ez egy kis munka, talán 10 másodperc! De sok embernek ment el a kedve az ilyen beállításoktól, szerkesztésektől, mert egypárszor kudarcélménye volt, ha valamit átírt, és azután nem ment a program. Mivel nem volt mentése, nehézkes volt a hibajavítás.
Szerkesztés? Akkor kell egy+egy szerkesztő program!
Igen, egy kezdőnek érdemes kettő programot megismerni. Minek? Elég egy is! Igen, ha ismersz egy terminálos szövegszerkesztőt, és van gyakorlatod, akkor elég egy is. De egy kezdőnek nem biztos, hogy a vi, vim stb. vonal lenne a jó! Bár a hardcore programozók mást mondanak, de nem vagyok biztos, hogy nekem, aki párszor belenyúl ebbe-abba a vi/vim egyikét meg kellene tanulnom.
Ismerj meg egy terminálos programot, ideális, ha pld. a nano vagy hasonlót megismered. Ha bármi gond van, akkor a terminálból ezzel nagyon jól tudsz dolgozni. Illetve több olyan program van, aminek a config fájljait nem simán megnyitod, hanem egy kötött módszerrel tudod csak szerkeszteni. Ilyen esetben nem a grafikus program nyílik meg, hanem alapesetben valamelyik terminálos szerkesztő és be lehet állítani, hogy ez a nano legyen.
Ismerj meg egy grafikus szerkesztőt is. Ez már kisebb trauma egy Windowsról áttérőnek, mert ezek már a megszokott kényelmes programok. Én nem ajánlok eset sem, csak jelzem: sublimetext3 vagy a geany amit én használok. Bár gyakorlatilag bármelyik olyan szerkesztő jó, ami sima txt fájlba is ment, de én mindenképp kerülném az office programokkal való szerkesztést. Kifejezetten nem kellene AbiWord, Libre/Open/FreeOffice, Calligra kategóriákat használni. Az legyen a célod a választásnál, hogy kódkiemelést, szintaxis kiemelést is tudjon. Így szépen kulturáltan tudsz dolgozni. Egyet! Nem kell fel tucat programot megismerni, egyet ismerj meg, és azt használd.
Hol vannak ezek a dot fájlok?
Alapesetben a ~/.config, azaz a saját könyvtárad egyik rejtett mappájában, vagy a saját könyvtáradban, vagy a gyökérkönyvtárban a /etc-ben (ezek jellemzően az egész rendszerre vonatkozó configok), vagy akárhol máshol. A ~/.config és a /etc egy viszonylag jól átlátható mappa, jellemzően a programok nevei szerinti könyvtárban találjuk a hozzájuk tartozó configokat. Ha nem? Na akkor el kell olvasni a leírásokat, a man oldalakat. Ami nálam abban merül ki, hogy ha valamit nem találok a viszonylag standard mappákban, akkor a google varázslatos erejéhez fordulok: rákeresek. Egyes disztribútorok sajnos elég gyakran ide-oda rakosgatják a beállító fájlokat, könyvtárakat. Így eltérhet disztribúciónként is a mappák, a fájlok fellelhetősége. Szuper, keverjük össze a kezdőt!
Ha végképp nem találsz meg valamit, akkor a kedvenc fájlkezelőd keresője segít.
Bár erre sincs szabvány, de jellemzően rc, xml, conf, config a kiterjesztése ezeknek, bár itt is elég vegyes a kép. Ahogy látni a kiterjesztéseknél a s fájlformátum eltérő lehet. Ami nem jelent gondot, mert egy xml fájl is jól strukturált, kis gyakorlattal jól átlátható sima szövegfájl. Így nem kell rögvest becsukni pld. az openbox rc.xml-jét, mert tele van krix-kraxokkal!
Megtaláltam, szerkesztettem, és nem engedi menteni!
Megszokott hiba, és a megoldást mindeni ismeri: nincs jogod ehhez. Ökölszabályként jegyezd meg: ami a könyvtáradban van (home/laci pld.) az a tied, és szerkeszteni tudod. Ami a fő, a gyökérkönyvárban van, és az abból nyíló mappákban, az nem a tied, és nem fogod tudni szerkeszteni. Ehhez emelt jog kell, azaz sudo, vagy root-ként kell belépned. Ami root-ként szerkeszthető csak, az értelemszerűen komolyabb, fontosabb, az egész rendszert érintő fájl. Kiemelten figyelj ilyenkor. Mentesz egy másolatot, majd odafigyelve szerkeszted, ellenőrzöd és csak azután véglegesíted a változtatást.
Hogyan lehet ezekkel gyorsan dolgozni?
Pár config kivételével a kiválasztott szövegszerkesztővel dolgozunk. De van pár olyan, ami ettől eltér: visudo, crontab -e stb. Ilyen esetben mindig érdemes az ajánlott, elvárt módszert használni. A legtöbb esetben ez a módszer ad egybizonyos ellenőrzést, hogyha valamit a visudo-val elrontsz, akkor rákérdez, hogy valóban akarod-e menteni. Program leírásában ott lesz, ha nem csak a „nyisd meg valami szerkesztővel” elvet kell követni. Alapesetben érdemes egy bejegyzést tenni a .bashrc, .zshrc (amelyik shellt használod) fájlba:
export EDITOR='program'
A program lehet pld. nano, ncedit vagy amit te alapértelmezett terminálos szerkesztőnek szeretnél. Így felülbírálod az alapértelmezett szerkesztőt, és az ilyen különcködő programok azzal nyílnak meg.
A többinél egyszerű a folyamat: kedvenc fájlkezelőddel odaléptetsz, csinálsz egy másolatot, majd megnyitod, és szerkeszted, és ha kész mented. Ebben semmi újdonság nincs. Ha heti egyszer, kétszer szerkesztesz fájlokat ez szuper. Ha többször, akkor már a biztonsági mentést, azaz a fájl másolat készítést érdemes egy, a fájlkezelődbe megírt paranccsal megoldani. Én a spacefm-et és a krusader-t használom, ezek (és nagyon sok másik is) jól programozhatóak. Ha jól emlékszem a krusader bemutatásánál pont egy ilyen másolatkészítőt mutattam. Az Arcolinux mit tartalmaz videóban is dicsértem a készítőt, hogy az openbox rc.xml-jét ha jobb klikkes menüben nyitom meg, akkor egy biztonsági másolat készítéssel kezdi… Azaz nem csak az én gyávaságom a biztonsági másolat!
A módszer jobb kivitelezése
Ez a módszer nekem csak akkor jó, ha egy-egy fájlt kell módosítani, amit egyszer megteszek, és kész. Nem túl hatékony, ha van pár olyan fájl, amit sokszor használok, sokszor módosítok. Ilyen pld, az openbox-os rc.xml, és a crontab, amibe az időzítések kerülnek. Sokszor belefutottam abba, hogy egy fájlkezelő megnyit, oda navigálok, mentem a fájlt másolatban, megnyitom művelet több időbe került, mint az, hogy az rc.xml-be beírok pld. egy gyorsbillentyűt. Nem hatékony, és sokszor inkább hagyom a fenébe a szerkesztést, mert a vele járó macera több, mint az eredmény. A lustaság szép erény? 🙂 Hogy kikerüljem ezt a problémát és rögvest a sokat szerkesztett config (a példában a rc.xml) nyíljon meg, legyen mentés is, egy nagyon puritán, de jó megoldást használok.
Azaz a feladat: Terminálból indítom a szerkesztést, de előbb mentést készítek, majd megnyitom a kiválasztott szerkesztővel.
Az első lépés explicit megadni a mentési fájlt, és annak a formátumát. Én a „dátumot tegyük hozzá” elvet követem, mert így valóban első látásra egyértelmű lesz a mentés ideje, és nem lesz probléma két azonos fájlnévvel sem. Ha _old a mentési kiterjesztés (rc.xml_old) akkor a második mentésnél már problémás lesz a munka: siránkozhat, hogy van ilyen fájl.
Valami ilyent gondolj el:
cp /home/laci/.config/openbox/rc.xml /home/laci/.config/openbox/rc.xml_$(date +%m%d_%H%M)
A végén egy parancs behelyettesítést alkalmaztunk, a date –help pedig megadja a kapcsolók értelezését. Ennél szebb, és informatívabb dátum, idő formátumot is használhatsz, de nekem ez bőven elegendő: rc.xml_0706_1326.
Ok, ezután már csak meg is kell nyitni a szerkesztendő fájlt:
subl3 /home/laci/.config/openbox/rc.xml
Szuper, már szerkeszthetem is, de előbb érdemes lenne ezt úgy megoldani, hogy egy, maximum két karakter leütése után le is fusson. Ezt kétféleképp oldhatjuk meg. Az egyik, ha aliast készünk, a két parancs közé meg egy && jelet teszünk.
alias r="cp /home/laci/.config/openbox/rc.xml /home/laci/.config/openbox/rc.xml_$(date +%m%d_%H%M) && subl3 /home/laci/.config/openbox/rc.xml"
Szuper, a terminálba egy sima r és már meg is nyílt, és van is mentésem!
A másik már egy összetettebb, de egyszerű megoldás. Scriptesítjük a munkát, a case szerkezetbe simán beírjuk egymás után a kívánt sorokat, megfelelő kapcsolókat is kitaláljuk és a scriptnek adunk egy egyszerű nevet pld. w és a fenti sor kapcsolója legyen r. Ekkor a w r beírása után már a kívánt config fájl szerkeszthető is.
Jogos kérdés lehet, hogy ha nyitva hagyom a fájlokat a szerkesztőben külön füleken, akkor az miért nem jobb. Mert egy idő után túl sok fül lesz, majd becsukom az összeset, és akkor indulhat elölről a keresgélés.
Bár az elő olvastában ez igencsak agyonbonyolított, túlzott megoldás, de vegyük észre, hogy ha a fenti egy sor kész, akkor csakis másolni, majd egy sima csere az elérési utaknál és kész a következő sor. Így már nem is olyan nehézkes az elkészítése. Amióta ezt a megoldást használom, nem volt problémán a szerkesztéssel, mert ha valamit elrontottam, akkor vissza tudtam állítani. Amióta így használom, azóta bármilyen kicsi változtatást is rögvest megteszek, hiszen egy terminál, egy betű és már ott is van a nyitott config fájl. Ami pedig ennél is jobb: nem marad el lustaság miatt egy változtatás sem.
Ajánlott sorrend:
1, skel felkutatása, átnézése
2, mentési folyamat összeállítása
3, szerkesztők kiválasztása (nano+sublime)
4, alias, vagy script, ha sokat…
Bár lehet, hogy sokan azt vártátok, hogy valami igencsak titkos trükköket osztok meg, amivel pár sor
beírásával már minden megoldódik, de sajnos ilyen nincs. A config azaz a dotfájlok szerkesztése, karbantartása egy összetett feladat. Nincs egységes megoldás, a szerkezetünk, formátumuk más és más. Így mielőtt bármit is tennél, olvass utána. A legkisebb változtatáshoz is legalább két forrást olvass el, mert nem biztos, hogy amit az interneten írnak, az biztosan jó lesz neked. Nagyon sok elavult és régi iromány lelhető fel, amiben olyan, akkoriban jó, de már idejétmúlt dolgokat tárgyalnak.
A szokásos szöveget rövidre fogom: csak akkor és azt, amit tudsz, és biztos vagy benne. Oda kell figyelni, pontos munka fontos. 🙂
Kb. ennyi.