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


A halőr diadala
2002. év 9. szám

...engem viszont az egyfedelű, minimalista megoldások tesznek boldoggá.

Januári jegyzetem legvégén azt ígértem, hogy a MagyarOffice-szal folytatjuk, valamelyest korábban pedig azt, hogy a Vimmel; most némi hezitálás után akként határozok, maradjunk az időrendnél, azaz jöjjön előbb a Vim. Ezt a meggondolást látszik alátámasztani egyebek között az a körülmény is, hogy a MagyarOffice e szöveg végleges elkészültének és leadásának napján érkezett meg hozzám, a Vim legfrissebb verziója pedig még tavaly. Másfelől a Vimmel kapcsolatban csontig ható sikerélményekkel gazdagodtam nemrég, s e körülményről mindenképp értesíteni kívánom a nyájas olvasót, harmadsorban értesíteni kívánom őt arról is, hogy a Vim immár bárki normális embernek javasolható, minthogy akár a Windows-alkalmazások viselkedését is hajlandó utánozni, ha éppen ezt várjuk tőle. (Amúgy ezt már az 5.8 is tudta, de a 6.0 jobb.) Végezetül van még egy apróság, hogy tudniillik én kedvelem a Vimet, szívesen dolgozom benne és ennek megfelelően örömmel beszélek róla, ha szabad. És mért is ne szabadna, ugyebár?


Szegény és gazdag textusok

Most tehát egy nagy múltú kódszerkesztő legeslegfrissebb változatának nem mindenestül előzmények nélkül való magasztalása következik, mégpedig elsődlegesen a civil élet perspektívájából, ami önmagában véve is némi magyarázatra szorul. Hogy mindenki számára világos legyen, miről van szó, három dolgot kiemelek, mintegy előhang gyanánt, utána pedig kedvenc rögeszméim taglalásával folytatom.
Először: a Vimnek kevesebb mint egy másodperc kell ahhoz, hogy elinduljon és megnyisson egy tizenöt megabájtos szövegállományt. Irodai szövegszerkesztőknél ez általában nem pontosan így alakul.
Másodszor: öt éve használom a Vimet, összeomlani még sohase láttam. Ugyanezt egyetlen általam ismert irodai szövegszerkesztőről sem tudom elmondani.
Harmadszor: vegyünk egy példát. Legyen egy terjedelmes, mondjuk, több száz oldalas szövegünk, amiben meg kell találnunk egy forgalmi rendszámot. Semmit se tudunk róla, nem emlékszünk egyetlen betűjére, egyetlen számjegyére se, továbbá arra se, hogy milyen környezetben fordul elő, csak annyit tudunk, hogy rendszám, három nagybetű, kötőjel, három számjegy. Őszintén érdekelne, hogy nyájas olvasóm mi módon kívánná ezt a feladatot például a Wordben abszolválni. Vimben nincs gond, azt írom a parancssorba, hogy ":/\u\u\u-\d\d\d" (persze az idézőjelek nélkül), leütöm az Entert és ott a rendszám.
Vagyis a Vim mellett súlyos és roppant gyakorlatias érvek szólnak, más kérdés, hogy az embernek nemcsak gyakorlatias érvei vannak, hanem rögeszméi is, és ezek semmivel sem kevésbé fontosak.
Nekem például van egy egy némiképp korszerűtlennek látszó, mondhatni, archaikus óhajom, hogy tudniillik a szövegeim szövegállományban legyenek, nem DOC-ban, nem tömörített XML-ben (OpenOffice), de még csak nem is RTF-ben, hanem igenis TXT-ben. Azt akarom, hogy beléjük kukkanthassak a Midnight Commanderrel (Windows alatt a FAR Managerrel), kilistázhassam őket a less paranccsal, gyorsan átlapozhassak egy könyvtárt a headdel és így tovább; de a legfőbb indokom a grep. A grep révén óriási szöveghalmazokból olyan könynyedséggel szedem elő a kívánt anyagot, amilyenről a Windows-felhasználó álmodni se mer.
Mellékesen jegyzem meg, hogy a magam részéről a sortöréses szövegállományokat preferálom, amelyek tehát úgy festenek, mint egy gépelt oldal, ezek ugyanis könnyebben kezelhetők. A nem sortöréses változatokban a szövegszerkesztő minden bekezdése egyetlen sor lesz, ha pedig az így képződött szövegállományok nagyobb halmazába, mondjuk, a head révén bele kívánok kukkantani, akkor többé-kevésbé áttekinthetetlen betűmezőt látok. Ha a greppel kívánom előszedni azokat a szövegeimet, amelyekben a papírtörök szó szerepel, akkor megint tagolatlan betűtenger faltól falig.
Ugyanez sortöréses szövegekkel rend, alakiasság, fókazsír.
Évekig dolgoztam a Britannica Hungaricának, ők 852-es kiosztású sortöréses textállományban kérték a fordításokat, amelyek az én gépemen eléggé nagy számban képződtek, de jellegük folytán mégis könnyedén voltak kezelhetők. (Ebben azért a Magellan nevű remek és mára teljesen elfelejtett állománykezelő is szerepet játszott, minthogy azt használtam, és pontosan tudtam, mire való.) Mindez ugye, DOS/Windows alatt, ahol (1) szövegkezelő segédprogramok jóformán nincsenek, a szövegkezelés kultúrája, mint olyan, teljességgel hiányzik, (2) kétfajta kódkiosztás van (volt), konzolon a 852-es, egyébként meg az 1250-es, ami önmagában véve is aberráció.
De mi most nem az ösztönélet iszapos mélységeiben matatunk, hanem a pőre szöveges formátum előnyeit próbáljuk kidomborítani. Ezen belül a kemény sorvégek problematikája teljesen másodlagos, ugyanis a sortörések szempillantás alatt kidobhatók, visszarakhatók vagy áthelyezhetők, legalábbis Unix/Linux alatt, ahol az Unix szó most a Windowsra húzott karakteres Unix köntöst (Cygwin vagy UWIN - http://www.research.att .com/sw/tools/uwin/) is jelentheti.
Ha tehát én azt akarnám, hogy a szövegszerkesztőm szépen nyomtatható (= formázott) dokumentumokat gyártson, akkor e célra alkalmas szerszámot választanék, aminő például a LyX, vagy valamelyik irodai szövegszerkesztő, ámde én nem szépen nyomtatható, hanem egyszerűen kezelhető (= formázatlan) dokumentumokat akarok tárolni, pőre szövegeket tehát. Ugyanis szövegelőállító szakiparos vagyok, nem pedig mestercukrász, thai sexmasszőr vagy holisztikus pszí-sebész.
Mellesleg még az sem igaz, amit előbbiekben a szépen nyomtatható dokumentumokról írtam, ugyanis én azokat is a Vimben hoznám létre, nem pedig a LyX-ben. Amikor már készen vannak, akkor importálnám őket, ugyanis a LyX (1. kép


Apu, hogy megy fel?

Három nem irodai szövegszerkesztővel alakítottam ki mélyebb kapcsolatot: az egyik a DOS alatt futó Personal Editor 3, a másik a Windows alatt futó NoteTab, a harmadik az összes létező operációs rendszer alatt futó Vim. Közülük a Personal Editor 3 aránylag egyszerű képződmény, a NoteTab egyszerűen kezelhető, a Vim pedig bonyolult és nehezen tanulható, viszont aki megismeri, beleszeret. Persze az is kérdéses, hogy mi az, ami nehezen tanulható, például hogyan viszonyul e tekintetben a Vim használata a vizuális antropológiához, az újszövetségi exegézishez vagy az ökonometriához. Mindenesetre a Vim elődje, a vi editor 1976-ban, a Microsoft előtti barbár korok sötétjében született, amikor a fejlesztők még nem tudták, hogyan kell programot fejleszteni, sőt azt hitték, hogy jól használhatónak az az alkalmazás tekinthető, amelyik jól működik. Ezzel szemben ami rosszul működik, az rosszul használható, így gondolták a mitikus idők csiszolatlan gondolkodású programozói, s ennek megfelelően a vi azzal a céllal jött létre, hogy szövegeket lehessen benne szerkeszteni, nem pedig azzal, hogy különféle hipotetikus felhasználók hipotetikus igényeinek megfeleljen. Így aztán érthető, hogy az ős-vi semmiben se hasonlít a ma használatos alkalmazásokhoz, ezzel szemben gyors és hatékony. A Vim azért egy csoda, mert próbál ugyan valamelyest megfelelni a mostani korszellemnek, de ettől nem lett rosszabb, mint a vi, hanem éppoly gyors és jóval hatékonyabb. Természetesen a Vim kódszerkesztő, vagyis programozói editor, de kiválóan alkalmazható minden olyan esetben, amikor abszolút formázatlan, pőre szöveget rögzítünk. Például azzal a céllal, hogy egy következő lépésben valamilyen kiadványszerkesztő rendszernek adjuk tovább.
Most előbb azonban a 6.0-s verziót kívánnám telepíteni. Természetesen a SuSE Linux is tartalmaz egy Vim-változatot, jelesül a 6.0av bétát; valamelyest korábban a Windows alatt futó 5.8-ast használtam, azelőtt az 5.6-ost, és így tovább a 4.0-ig visszamenőleg. Ennek alapján annyit mindenképp nyugodt lélekkel mondhatok, hogy a Vim verzióról verzióra javul és gazdagodik, ergo mindenképp indokolt, hogy a 6.0 végleges változatát föltegyem.
Windows alatt ilyenkor rákattintunk egy állományra, ami általában a setup nevet viseli, és ettől az alkalmazás fölmegy, mint az állat. Linuxnál tar.gz formátumban tömörített forráskódot töltünk le, azt előbb kicsomagoljuk, aztán lefordítjuk, és ugyanazzal a lendülettel telepítjük is.
Nem nagy ügy, egy informatikailag alulképzett halőr is kacagó gerleként birkózik meg vele.
Elsőre ugyan nem sikerül, de rájövök, hogy ez azért van, mert a forráskönyvtárnak közvetlenül a home könyvtár alatt kell lennie, nálam meg egy szinttel lejjebb volt. Másodjára se sikerül, de rájövök, hogy a fordításra-telepítésre vonatkozó parancsot rendszergazdai minőségemben kell kiadnom. Kiadom úgy, ám a telepítés harmadjára se sikerül, ugyanis a folyamat vége felé létre kéne jönnie egy config.status nevű állománynak, ám az a jelek szerint nem jött létre.
Azért megnézem a saját szememmel is, de csakugyan nem jött létre.
Kihajítom az elhasznált telepítőkönyvtárat, és új példányt csomagolok ki a letöltött tar.gz állományból, aztán átlényegülök roottá, make install, rengeteg minden történik, de a végén a config.status megint csak nem jön létre.
Kiderítem, hogy a létre nem jövő config.status egy shell script, amit egy másik shell scriptnek kéne generálnia. Az a script megvan, hibátlan, benne vannak a megfelelő utasítások, működik is, egészen addig, amíg a config.status legyártása sorra nem kerül. Azt ugyanis már nem csinálja meg.
Ha a benne föllelhető és erre vonatkozó utasításokat egyenként beírom a promptnál, akkor a config.status megszületik. Ha ugyanezt a script műveli, akkor nem.
Természetesen egy vastagtudományú, gyakorlott rendszeradminisztrátor eddigre rég kitalálta, hol a bibi, ámde én nem vagyok vastagtudományú, gyakorlott rendszeradminisztrátor, hanem egy halőr vagyok, és ezzel együtt fel kell tudnom rakni ezt a nyavalyát. Windows alatt egy ilyen szintű feladattal nemcsak egy halőr, hanem egy csősz is megbirkózik, sőt a csősz süketnéma anyósa is, a Linux pedig - a hírek szerint - most már semmivel se kevésbé felhasználóbarát, mint a Windows, úgyhogy itt is minden megoldódik hamarost.
Mintegy tizenhárom újabb próbálkozás következik, ám a config.status nem jön létre, a telepítés minden alkalommal leáll.
És mit ad isten, egyszer csakugyan rájövök. Hogy honnan, azt nem tudom, sehol semmifajta erre vonatkozó utalást nem olvasok, csak épp a config.status generálására hivatott script első sorára téved a tekintetem, és ott az áll, hogy #!/bin/sh. Nekem pedig földereng valahonnan, hogy a bash másképp viselkedik akkor, ha sh-nak szólítjuk, és megint másképp, ha bashnak.
Megint előállítok egy teljesen szűz telepítő-könyvtárszerkezetet, abban a scriptállományok első sorát #!/bin/sh-ról egy menetben mindenütt #!/bin/bash-ra javítom, aztán make install megint, és íme, a Vim 6.0 a helyére megy.
Hát ez az a csontig ható sikerélmény, amit az első bekezdésben említettem, egyben ez a halőr diadala és a türelem gyümölcse. Nem kell kapkodni, nem kell idegeskedni, idővel minden összejön valahogy. Vagy legalábbis reménykedjünk.


Néhány szó a családi gazdaságokról

A Vim 6.0 egy lehetséges arculatát a 2. képen

Váncsa István



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