Technológia Trendek Telekommunikáció Társadalom Állás
IDG News

Hírlevelek
Iratkozzon fel hírleveleinkre!

 Napi hírlevél
 Biztonság
 Hardver
 Távközlés
 Üzleti megoldások
Archívum
Kiadó
IDG
IDG Hungary Kft.

1075 Budapest
Madách I. út 13-14.
A épület, IV. em.

Kapcsolatfelvétel,
információ, észrevétel


Legkedvesebb szakócám dicsérete II. rész
2004. év 14. szám
Váncsa István

Folytatódik az Emacs ismertetése, melynek keretében a vázlatmód örömeitől az Alattomos Nagy Testvér Adatbázisáig, illetve a csontvázkezelésig jutunk

Múlt havi jegyzetem az nXML megjelenéséről szóló örömhírrel indult, az nXML valójában a GNU Emacs kiterjesztése, melynek következtében ez a tiszteletreméltó korú szabad szoftver hirtelenjében megint a technológiai fejlődés élvonalában találja magát. Ennek örömére áttekintettük, hogy valójában mi is az Emacs, milyen hasznát vehetjük a polgári életben, mit gondoljunk a Lispről, mi a helyzet az Emacs idegenszerű sajátosságaival, hogyan lehet ezekkel együtt élni és ennek fejében milyen szerkesztőeszközöket kapunk. Most egy további szerkesztőeszközzel, a vázlatmóddal folytatom, majd az Emacs felhasználói felülete következik, aztán a dired, az Eshell, a különféle levelező-alrendszerek, legvégül pedig a Gnus.

A vázlatmód örömei

Ez a jegyzet a maga módján strukturált dokumentum, amennyiben részekre oszlik és a részeket alcímek választják el egymástól. Továbbá elég terjedelmes ahhoz, hogy ne legyen túl egyszerű navigálni benne. Erre találták ki a vázlatmódot, amit nemcsak az irodai szövegszerkesztők ismernek, hanem a jobb editorok is, mint például NoteTab Pro, Vim, Emacs. A NoteTab Pro csakugyan jó darab, bárha fizetős (húsz dollár), viszont a vázlatmódjának vannak hátrányai, egyebek között előre el kell döntenünk, hogy a szöveg vázlatmódban készül-e vagy sem. Csak hát a felhasználó nem Cassandra, hogy a jövőbe lásson. A Vim az ő vázlatmódját foldingnak nevezi, valamikor használtam is (mármint a Vimben foldingot), most megint belenéztem a dokumentációjába, és már ettől is zúgni kezdett a fejem. Viszont az Emacsnél az outline mode már nem is lehetne egyszerűbb. A szöveget szöveges módban kezdem el írni, ha aztán a tartalom idővel nagyon elterebélyesedik, és már alcímeket is pakoltam bele, átváltok vázlatmódba, M-x outline-mode, ennyi az egész, amúgy minden marad a régiben, csak most már az Emacs látja az alcímeket, elkülöníti őket a szövegtől, és másképp kezeli. Persze ehhez jelölnöm kell őket valahogy, alapértelmezés szerint a vázlatszintnek megfelelően egy vagy több csillagot rakunk a címek elé, de lehet ez másképp is. Én például a szerkesztőség tájékoztatása érdekében oda szoktam írni a címek elé, hogy ((főcím)), ((cím)), ((alcím)) és hasonlók, tehát úgy döntöttem, hogy nálam a címeket egyszerűen a (( karakterpár jelöli. Ennek a megvalósításához nem kell könyékig belemászni a menübe, ehelyett M-x customize-set-variable, Enter, outline-regexp, Enter, ((, Enter, és meg is vagyunk. Persze ha azt akarom, hogy az Emacs ne csak itt ismerje fel az alcímeket, hanem olyan dokumentumokban is, amelyek másfajta konvenciók szerint íródtak, akkor az a bizonyos reguláris kifejezés -­ az outline-regexp ­- némileg bonyolultabb lesz. Viszont ennek fejében az Emacs nemcsak ennek a jegyzetnek a közcímeit ismeri fel automatikusan, hanem készülő terjedelmesebb munkám fejezetcímeit is, más színnel jelöli őket (syntax highlighting), billentyűkombinációkkal ugrálhatok címről címre, illetve alcímről alcímre, a köztük lévő szöveganyagot pedig eltüntetem vagy elővarázsolom kedvem szerint. Természetesen tudok navigálni az egyes ágakon belül is (ha vannak), az ágakat kivághatom és beolthatom máshova, ahogy ez a hasonló esetekben történni szokott.

Parancssori vigasságok

Fentebb előfordult néhány furcsa kifejezés, az M-x outline-mode meg az M-x customize-set-variable, ezek magyarázatra szorulnak, a magyarázat az Emacs felhasználói felületének sajátosságaiban rejlik. Ez a felület parancssoros, bár nem annak mondják, a parancssorának pedig nem parancssor a neve, hanem minibuffer, ám ez a tényeken nem változtat. Az Emacsnek igen nagyszámú belső parancsa van, egy adott billentyűkombináció vagy menüpont (amennyiben egyáltalán használunk menüt) mindig a megfelelő belső parancsot aktiválja, majd a feladat végrehajtódik. Ha például vissza akarok lépni egy betűvel, akkor -­ éppúgy, mint bármely más alkalmazásban -­ megnyomom a megfelelő kurzorbillentyűt, vagy leütöm a C-b billentyűkombinációt, ahogy az Emacsben szokás. De az is lehetséges, hogy közvetlenül a parancs nevére hivatkozom, azaz beírom a parancssorba, M-x backward-char, hiszen a kurzorbillentyű is ezt a parancsot hívja, a C-b gyorsbillentyű úgyszintén, vagyis ez utóbbi dolgok esetlegesek, azt rendelek a parancshoz, amit épp akarok. Avagy, mint mondtam, meghívom név szerint. Persze igen kicsi a valószínűsége annak, hogy az ember a parancs teljes nevének használatával lépjen vissza egy betűt, ugyanakkor az Emacs funkcióinak egy jelentős részéhez így férünk hozzá leghamarabb. Mondjuk, tudni szeretném, mikor van legközelebb telehold, M-x phases-of-moon, Enter, és ott egy lista a holdfázisokról, az előző hónap, az aktuális hónap, meg a következő. Nyilván meglepő kissé, hogy egy szövegszerkesztő még ezt is tudja, de hát az Emacs járatos egyebek között a kínai, kopt, etióp, héber, perzsa, maja stb. naptárakban is, ehhez képest a holdfázisok ismerete pimf dolog. Engem amúgy nem érdekel, mikor van telehold, viszont ez jó példa a parancssor ­- vagy legyen minibuffer, bánom is én ­ használatát illetően. Az M-x azt jelenti, hogy leütöm az Alt-X billentyűkombinációt, ettől a parancssorba (minibufferbe) kerülök, most jöhet a parancs, amivel kapcsolatban elég csupán annyit tudnom, hogy mit is akarok. Holdfázisok kellenek nekem, angolosan phases vagy ilyesmi, beírom tehát, hogy pha, megnyomom a tabulátort, és ott áll, hogy phases-of-moon. Bingó, ha szabad így mondanom. Tehát a parancssorban (minibufferben) igen hatékony parancskiegészítés van, elég lett volna, ha csak ph-t írok be, akkor is megjelent volna a phases-of-moon, ha viszont csak p-t találok írni, akkor megkapom mind a hatvan lehetséges folytatást, első a paragraph-indent-minor-mode, az utolsó a pwd, ami az aktuális könyvtár nevét és elérési útját adja vissza. Persze lehet, hogy nyájas olvasóm ezzel együtt inkább a menürendszerhez ragaszkodna, ugyanakkor persze az is lehet, hogy nyájas olvasóm még sohase próbált egy klasszikus, nagy múltú rajzoló- vagy kiadványszerkesztő program menürendszerében mind reményvesztettebben föllelni valamit. Én próbáltam ezt is, azt is, ötvenszer inkább a parancssor.

Állományok, könyvtárak, commanderek

Valamikor régen, a boldogult DOS-időkben, amikor az operációs rendszer még nem szolgáltatta a szabványos Open és Save As párbeszédablakokat, ezt is az alkalmazások oldották meg, ki így, ki úgy. Némelyiknek (például WordPerfect) idővel teljes értékű állománykezelője alakult ki, az Emacs esetében ugyanez történt, csak persze egy jobb világban, értsd UNIX alatt, és kissé különös módon, amennyiben az állománykezelő látszólag ugyanolyan szerkesztőablakban jelenik meg, amilyenekben a dokumentumokat szoktuk látni. Sőt ez az ablak kettéosztható (vagy többfelé, de ez most mindegy), egyikben a szöveg, a másikban az állománykezelő. Valójában ez utóbbi is dokumentum, persze nem írható, viszont interaktív, ezzel együtt sok tekintetben dokumentumként viselkedik, ugyanúgy lehet benne mozogni, kijelölni, másolni, könyvjelzőt elhelyezni, mint a szövegszerkesztőben. Neve is ennek megfelelő, Directory Editor, röviden dired. Megjelenése a UNIX "ls -l" parancsának kimenetére emlékeztet, előbb a jogosultságok, aztán a tulaj, a terjedelem, az idő és végül az állománynév. Rendezési lehetőségekben nem bővelkedik, még ahhoz is trükközni kell, hogy a könyvtárakat ne keverje össze az állományokkal, hanem a lista elejére rakja őket. Ettől eltekintve a szokásos állománykezelői szolgáltatások mindegyikét nyújtja, persze tud annál többet is. Már maga az, hogy regulá- ris kifejezések alapján jelölhetek ki állományokat, adott esetben óriási előny. Emellett a dired reguláris kifejezésekkel keres állományokon belül, állományokat hasonlít össze, shell parancsot futtat a kijelölt állományokon és így tovább, és mindezt a lehető legmérsékeltebb billentyűnyomkodás ellenében teszi.
A dired egyablakos állománykezelő, viszont az Emacs bármelyik ablakát ketté lehet vágni, akár vízszintesen, akár függőlegesen, és akkor két ablakunk lesz. Ha dired-ablakot vágunk ketté, akkor lesz két dired-ablakunk, vagyis kétablakos -­ Commander jellegű ­- állománykezelőhöz jutottunk. Már csak azt kell megoldani, hogy működjenek benne a megfelelő funkcióbillentyűk (F3 = View, F4 = Edit, F5 = Copy és így tovább), és akkor van egy Midnight Commander-klónunk. Csakugyan létezik ilyen, bár nem része az alapcsomagnak, külön kell letölteni. Norton Commander-klón is létezik, abból a dired különféle funkciói nem érhetők el (a Midnight Commanderből igen), viszont ennek fejében karcsúbb, egyszerűbb, emberibb formája van, és mintha csak a DOS-érában volnánk, a nyolcvanas évek vége felé.

Eshell

A dired belső szépségeit akkor fogjuk igazán méltányolni, ha ezt a jeles állománykezelőt az Eshellel együtt veszszük használatba. Ez utóbbi, mint azt a múlt hónapban is említettem, a TC shellel és a Z shellel egyenrangú, sőt bizonyos tekintetben mindegyiknél jobb. Persze nem túl nagy annak a statisztikai valószínűsége, hogy a fönti kijelentés nyájas olvasómat fölcsigázza vagy mélyen megrendíti, bár ki tudja. Jómagam mindegyik UNIX shellt kipróbáltam a gyakorlatban, elsőként nyilván a basht, aztán a C shellt és a Korn shellt, de csak épphogy, a TC shellt valamivel tartósabban, végül lehorgonyoztam a Z shellnél, részint mert ez az ábécében az utolsó betű, részint meg azért, mert nem hiányzik belőle semmi. Az Eshell mégis hozzá tud tenni néhány apróságot, az egyik a cd-history. Tegyük föl, hogy vissza akarok jutni a d:egyedem\egyedem\ikkmakk\akfitty alkönyvtárba, ahol már jártam egyszer, mondjuk, két héttel ezelőtt, nos, ehhez elég annyit beírnom, hogy cd=bikk, és ott vagyok a bakfittyben ­- illetve utolsó olyan látogatott könyvtárban, amelynek elérési útjában a bikk karaktercsoport szerepel. (Az egyenlőségjel után reguláris kifejezés is állhat.) A másik az aliasek, más szóval parancshelyettesítők kezelése. Tegyük fel, hogy sikerült összehoznom egy jó hosszú és bonyolult parancsot, ami mégis működni látszik és amire vélhetőleg szükség lesz máskor is, azt a history segítségével visszabűvészkedem a prompthoz, elé írom, hogy alias hokuszpokusz, ahol a hokuszpokusz nyilván a választott álnév, Enter-t ütök, az Eshell pedig azonnali hatállyal lemezre menti az új aliast. Ilyen máshol nincs, hanem az van, hogy az aliasokat külön kell a megfelelő inicializáló állományba beírni. Nyilván nem kell magyaráznom, melyik a praktikusabb.
Parancskiegészítő mechanizmusa tökéletes, beírom, hogy rm, megnyomom a tabulátort, és ott a lista azokról az állományokról, amelyeket kitörölhetek, ha viszont az rmdir parancs után nyomok tabulátort, akkor a törölhető könyvtárak listáját kapom. Ha ezek a listák terjedelmesek, akkor új pufferben bukkannak elő. Az Eshell kimenete átirányítható a vágólapra, "whois europaterv.hu >> /dev/clip", és máris be lehet szúrni mondjuk egy Word dokumentumba mindazt az értékes információt, ami az europaterv.hu domainről kiderült. Persze efféléket más shellek is tudnak, viszont az Eshell az Emacs része, ezért a kimenetét át lehet irányítani közvetlenül bármelyik szerkesztett dokumentumba (pufferbe), beírom, hogy "h >> #;", és megjelenik itt alant a history, amit most persze kitörlök. Egyébként az Eshellnek ablak se kell, hiszen, mint mondtam, az Emacs valójában parancssoros. Leütöm az M-! (értsd Alt-!) billentyűkombinációt, ettől a parancssorba kerülök, de az már a shell parancssora, beírom, hogy idg2dtk, ez egy alias, amely erről a szövegről a helyi hálózat másik gépének megfelelő könyvtárában biztonsági mentést csinál.
Ma már a Linux-felhasználó is kerüli a parancssor használatát (hacsak nem Linux-gururól van szó), ugyanis elhitették vele, hogy ez korszerűtlen, elavult dolog. Nem tudja szegény, mit veszít.

Levelezés, hírek, RSS

Levelet ugyanúgy írunk az Emacsben, mint akármi mást, persze a levél első sorban eleve ott áll, hogy To:, a másodikban pedig az, hogy Subject:, további különbség nemigen mutatkozik. Ha kész, leütöm kétszer a C-c (Ctrl-C) billentyűket, és a levél elmegy. Lássuk be, semmi értelme nem volna annak, hogy e célra egy különálló, úgynevezett levelezőprogramot indítsak el, és közben az Emacset magam mögött hagyjam. Levelet írni: szövegszerkesztés, az Emacs pedig szövegszerkesztő, az egyik legjobb. A levélolvasás már kissé komplexebb ügy, leveleket szűrni, rendezni, visszakeresni speciális alkalmazásokkal szokás. Magától értetődik, hogy az Emacs mint Lisp alapú, továbbfejleszthető, integrált környezet különféle levelezőklienseket is tartalmaz, lehet válogatni közöttük. Mindegyiknek saját e-mail formátuma van, ez mindig egyszerű textformátum, s ennek ellenére mégse kompatibilisek egymással, egyik program a másik inboxát nem tudja elolvasni. Noha ez is szövegállomány meg az is szövegállomány, továbbá ez a program is Emacs alrendszer, és a másik is az.
Hihetetlen dolgokra képes az emberi elme.
Az első ilyen Emacs-alrendszer az Rmail, az mindig benne van az alapcsomagban, bár nem mindig működik. Az Rmail ugyanis nem akar postát letölteni POP3-kiszolgálókról, továbbá IMAP4-postafiókokat sem kíván látogatni, hanem csak a helybeli inboxot. Feltételezi, hogy UNIX jellegű rendszeren vagyunk, tehát van nekünk valahol egy mail nevű alkönyvtárunk, vélhetőleg a /var/mail, /var/spool/mail, esetleg az /usr/mail címeken, rendszere válogatja, azon belül van egy inbox nevű állomány, amihez a beérkező postánkat egy e célra rendszeresített alkalmazás folyamatosan hozzácsapja. Természetesen minden UNIX jellegű rendszeren megoldható, hogy ez csakugyan így történjen, továbbá megoldható Windows alatt is, ha a Cygwin környezet telepítve van. Ezzel együtt az átlagfelhasználó ahhoz szokott, hogy a levelezőprogramja letölti a postát, ebből következően az átlagfelhasználó az Rmailnak annyira nem örül.
Következzen, mondjuk, a VM nevű alrendszer, ez már nem okvetlenül található meg az alapcsomagban, amellett külön verziója van az Emacs 19.x-hez, külön az Emacs 20.x-hez, külön az XEmacshez, ami pedig az általam használt Emacs 21.2-t illeti, ahhoz nincs egyáltalán. Vele kapcsolatos tapasztalataim tehát nem túl frissek és nem is túl markánsak. Világképe az Rmailéhoz hasonlatos, tehát valamilyen spool állományt kell neki mutatnunk, de az az állomány POP vagy IMAP kiszolgáló is lehet, amennyiben a vm-spool-files nevű változónak megfelelő értékeket adunk. Utána nincs vele gond. Persze nem sok értelme van annak, hogy a levelek letöltésével is egy Emacs-alrendszert bízzunk meg, amikor a fetchmail ezt sokkal ügyesebben műveli.
Említést érdemel az MH (Message Handler vagy Mail Handler, mondják ennek is, annak is) nevű képződmény, ami már nem Emacs-alrendszer, minthogy az Emacs csak felületet ad hozzá, más szóval bekebelezi. Első változata egy Rand Corporation nevű nonprofit tanácsadó szervezet számára készült, aztán a University of Californián fejlesztették tovább. A klasszikus UNIX mail képességesebb utódát tisztelhetjük benne. Számos megjelenési formája ismert, a már említett MH nevű alapváltozat mellett van xmh, exmh, mh-e és nmh is. Ez esetben, bármily meglepő, nem a különböző verziók kölcsönös és teljes inkompatibilitása volt a cél, egyszerűen csak arról van szó, hogy az xmh és az exmh X alatt fut (az exmh Tcl/Tk-ban íródott), az mh-e az Emacs belsejében lakozik, az nmh betűcsoport pedig olyan új variánst jelöl, ami az elődökkel majdnem kompatibilis. Amúgy az MH igen jellegzetes, mondhatni, telivér UNIX-alkalmazás, amennyiben nem monolit program, hanem egyszerű, egyetlen célra alkalmas modulok vagy inkább programocskák halmaza. Futtatása se abból áll, hogy elindítjuk, majd leállítjuk, hanem abból, hogy vannak különféle MH-parancsok, amelyek más UNIX-parancsokkal is összekapcsolhatók, miáltal lesz móka, kacagás. Bánni tud a HTML-formátumú levelekkel, kezeli a szálakat, támogatja a spamszűrést, a levélállományt indexeli és így villámgyorsan keres. Ami az Emacshez készült változatot, tehát az mh-e jelű képződményt illeti, az valamivel régebbi, mint maga a GNU Emacs.
A csúcsot valószínűleg a Gnus jelenti, ő nem elsősorban levelezőprogram, hanem általános üzenetkezelő, azaz hírolvasó, nemkülönben RSS-aggregátor, és e tekintetben abszolút egyedülálló jelenség. Tudtommal nincs még egy olyan hírolvasó, amely levelezőprogram és RSS-aggregátor is volna egyidejűleg, és akkor még figyelembe se vettem, hogy ez a hírolvasó egy szövegszerkesztő csomag egyik alrendszere amúgy. (Nevének ejtése núz, ezt humornak szánták, mosolyogjunk. Egyébként a Gnus név alfa-verziója úgy hangzott, hogy: Warp GNUS NT: TNG Six.0 for Windows, a végső változat ennél azért sikerültebb.) 1995 óta része az Emacsnek, először a 19.30-as disztribúcióban volt jelen. Hírolvasóként a legjobbak között van, nagyjából az slrn-nel egy színvonalon, talán csak az Xnews ne- vű Windows-alkalmazás előzi meg, bár ez se biztos. Levelezőprogramként az e-mail-vírusokat nem támogatja, de ezenkívül mindenre képes, amire a modern e-mail-kliensek úgy általában, sőt többre is. Ha például elő akarom szedni Kulcsár Attila hozzám írt régi levelei közül az izgalmasabbakat, egy pillanat alatt megtehetem, hiszen a Gnus feladó szerint és szálak szerint is csoportosítja a leveleket, az együvé tartozókat kék selyemszalaggal köti át, úgy teszi el a sublót fiókjába, közéjük egy-két szál préselt virág jön, melléjük kevéske levendula.

Ami kimaradt

Vannak az Emacsben olyan dolgok is, amelyeket ebben a két jegyzetben meg se tudtam említeni, ilyen például a BBDB nevű félautomata kapcsolatkezelő, teljes néven The Insidious Big Brother Database, magyarul Az Alattomos Nagy Testvér Adatbázisa. A félautomata szó is és a Big Brother kifejezés is arra kíván utalni, hogy a BBDB ül a háttérben, figyeli a levél- és üzenetforgalmunkat, följegyzéseket készít, és döbbenetes adatbázist szerkeszt belőlük. Aztán itt van az EUDC, teljes nevén az Emacs Unified Directory Client, ami azért van, hogy az így létrejött adatbázist közös felületbe csomagolja az LDAP-böngészővel és azzal a valamivel, amit a CCSO PH/QI rövidítés jelöl, nem tudom, mi ez, de valami nagyon finom dolog lehet, így aztán szeretném, ha nekem is volna ilyen. A felhasználói felületnek is vannak itt nem tárgyalt, ámde praktikus elemei, amilyen, mondjuk, a Speedbar, továbbá vannak szerkesztőeszközök, amelyekre nem kerülhetett sor, ilyen például a csontvázak (skeletons) használata, vagy éppenséggel a HTML/ SGML/XML major mode-ok. Igaz, ezek közül egyet, az nXML-t legalább megemlítettem, vele indult a múlt havi jegyzet. Valamikor a nem túl távoli jövőben egyébként XML szerkesztőkről lesz szó, akkor majd az nXML-re is visszatérünk.

Kapcsolódó link
http://bbdb.sourceforge.net/
http://www.gnus.org/
http://www.ics.uci.edu/~mh/
http://www.notetab.com/ntp.php
http://www.wonderworks.com/vm
http://www.xemacs.org


Nyomtatható verzió   Küldje tovább e-mailben   Hozzászólások  

IDG Konferencia
2004. 11. 23.

Konferencia:
 Mobile content and
 business solutions


IT Cégek
Mutassa be cégét, vállalkozását olvasóinknak, leendő üzleti partnereinek!
Regisztráció  Cégbemutatók 
Szolgáltatások