Vlákno názorů k článku Vifm: správce souboru á la Vim od anonym - Jen takové upozornění ve verzi 0.3a (na Gentoo)...

Problémy s dlouhými názvy souborů, problémy s češtinou, problémy s terminály, a aplikace typu vi - to je vlastně stručný problém nectností unixů z pohledu uživatele. Naštěstí svět nejsou jen unixy.

Zajímavé, žádných problémů s dlouhými názvy souborů jsem si nevšiml - kromě CD vypálených na Unixu, která na Windows mají jen krátké názvy, protože Windows neumí Rock Ridge a do Joliet se ty skutečně dlouhé názvy jaksi nevešly. A Vim si můžete koneckonců stáhnout i pro Windows - třeba programátoři v Microsoftu, kteří používají GVim, ho určitě nepoužívají v Linuxu. ;-)

Jestli máte tyhle problémy, tak si nedělejte nic z toho, že si neumíte poradit, a prostě nepoužívejte Unix. Naštěstí pro Vás existují i Windows.

Zato já si všiml řady problémů. Například mezery v názvech řada skriptů nezpracuje, protože autoři s mezerami nepočítali (nedodělek). Podobně s češtinou v názvech souborů, která působí tolik problémů, že jí uživatelé unixů raději nepoužívají. A sám můžete vidět, že řada uživatelů unixů dodnes píše příspvěky a maily bez diakritiky (což s FS pravda nemá mnoho společného).

Takže ano, i já mám tyhle problémy. Ani já nemůžu nainstalovat Oracle do adresáře "oracle 10i", a dokonce ani v Oracle sqlplus použít příkaz spool "my file.txt", nebo dokonce "můj soubor.txt". Windows sice podobné problémy nemají, ale Oracle na Windows (coby port z unixu) bohužel ano.

Děláte, jako kdyby programátoři MS pracovali v GVimu. V MS možná existuje člověk, užívající *vi (možná dokonce pár lidí), ale zdaleka nejde o běžnou věc. Nakonec jste si mohl všimnout, že MS měl vlastní unix, portoval na unixy nějaký svůj SW (včetně MSIE a WMP), a občas pro unixy něco píše. A kdo je unixem dostatečně infikovaný, musí samozřejmě používat vi (a musí mu to připadat jako skvělý nápad).

Linux má samozrejme editorov hromadu, vrátane tých skvelých GUI ... niekomu vyhovujú viac, niekomu menej, a o tom to je - nútiť každého používať to Jediné A Správne Rozhranie (TM) je absurdné.

Inak je to zvláštne, ale mne napríklad tento 30+ rokov starý editor vyhovuje oveľa viac, a efektivita práce je v ňom pre mňa podstatne vyššia, než v prípade všetkých tých moderných IntelliSense a auto-refactoring a ja-neviem-čo-všetko záležitostí.

Třeba kulaté pneumatiky jsou daleko lepší, než hranaté. Nikdo nikoho nenutí používat Jediné a Správné Kulaté Pneumatiky (TM), ale je poněkud nesmyslné používat ty hranaté.

Pokud vám vyhovuje editor, který nemá nabídku, ve kterém nemůžete udělat věc pro kterou neznáte konkrétní příkaz, a který nemá vizuální odezvu akcí, tak je to opravdu zvláštní. Spíše si myslím, že jste strávil velkou spoustu času a úsilí učením se něčeho naprosto zbytečného, a teď tu investici obhájit. Ve Visual Studiu když najedete myší na proměnnou, tak se vám zobrazí datový typ, IntelliSense vám doplňuje nejen vestavěné prvky jazyka, ale i jména vašich proměnných, tříd a metod, máte k dispozici GUI designer a integrovaný debugger, máte podporu pro makra a doplňky, a ovládání z klávesnice je realizované velmi dobře. Nemyslím, že by práce ve vi mohla být efektivnější, a to ani když strávíte absurdní spoustu času jeho učením. Předpokladem samozřejmě je, že umíte ovládat GUI z klávesnice (například umíte vybírat bloky z klávesnice), a naučíte se pár klávesových zkratek popsaných v menu.

Ty pablb, na rozdiel od teba on asi vie pouzivat obidva editory a dokaze si vybrat ten spravny. Ty o VI nevies vobec a mudrujes tu. To ze si ty nevies nieco predstavit nic neznamena pretoze nemas prehlad.

Tak v tom případě je asi jedině dobře, že Vim má grafický kabátek, nabídky, vizuální odezvu akcí, progamovatelné doplňování kódu, podporu pro makra a doplňky a hlavně velmi dobré ovládání v klávesnice, dokonce natolik dobré, že i někteří lidé v Microsoftu používají ViEmu ("Preventing carpal tunnel syndrome since 2005! :-]). Tohle je obzvláště zajímavé:

While I was at Microsoft, I hardly ever used Visual Studio. I edited my C/C++ code with Vim, I compiled and linked it with the NT Build Environment and I debugged it with WinDbg/ntsd/kd. I was hardly alone in this. In the Windows division, your code has to build with the NT build environment, and the Windows debuggers are much better supported than the Visual Studio debugger for developing the OS.

:-)))

Jestli máte na mysli GVim, tak ten mě také neoslovil.

Hm, jinými slovy bývalý zaměstnanec MS, který je 20 let nadšeným uživatelem vi/vimu, ho údajně používal i v MS, a podle vlastních slov prý nebyl sám. To je jistě pěkné, ale jistě uznáte, že je to stejně o ničem, jako kdyby bývalý zaměstnanec MS napsal, že v MS pil čaj s koňskou močí. Má to totiž podobnou vypovídací hodnotu v tom, jak je či není dobrý koncept UI vi/vimu.

No a jeden Lael Ophir zase kolem dokola tvrdí, že v MS nepracuje, ale že Windows jsou skvělé a my socky bychom si je už taky měli konečně pořídit. To má totiž asi podobnou vypovídací hodnotu v tom, jestli je skutečně potřebujeme nebo ne. :]

Plánujete sa zúčastniť súťaže o najabsurdnejšie prirovnanie ? ;) Prirovnávať Visual Studio k hranatej pneumatike, mno ... ono to VS zas -tak- zlé nie je, s trochou sebazaprenia sa s tým robiť dá ... :)

Viem že ste to asi mysleli opačne, ale proste som neodolal.

Ono vec, ktorú zjavne nie ste schopný pochopiť (alebo sa úmyselne tvárite, že ju nechápete) je, že občas proste existuje viacero možností, ako niečo môže fungovať, nie je tu (našťastie) len Jediný A Správny Prístup Veľkého Billa k Editovaniu Súborov :)

Prečo sa tak dobrovoľne zbavujete vlastného názoru ? Prečo si stále myslíte, že všetko, čo prišlo od jednej konkrétnej firmy, je dokonalé dielo božie o ktorom sa proste nediskutuje, a všetko ostatné je akosi pochybné ? Je to dosť zvláštne. Bolo by zaujímavé vedieť, či tým polopravdám a skresleným faktom, ktoré tak rád používate, fakt veríte, alebo ste motivovaný inak - finančne ? Ale pravdu o tomto mi samozrejme nepoviete.

Veľkú hromadu času som učením sa vi rozhodne nestrávil - vlastne poznám len základy - a napriek tomu je moja práca v ňom efektívnejšia než v týchto "inteligentných" nástrojoch (uvodzovky sú tam zámerne, keďže tieto vlastnosti sú často skôr na zlosť). Vim je neuveriteľne mocný nástroj - niekedy by ste si ho mali vyskúšať a pokúsiť sa ho pochopiť, nech aspoň viete, čo vlastne kritizujete.

Pokiaľ ide o absenciu menu a podobne - nedávno som na túto tému čítal zaujímavý článok, ktorý hovoril zhruba to, že používateľské rozhrania sú určené na *používanie* - nie na *učenie sa*. Dobré rozhranie je preto také, v ktorom môže efektívne pracovať človek, ktorý sa ho naučil, nie také, ktoré sa tvári, že sa ho učiť netreba, ale na serióznu prácu je nevhodné.

Všetky tie ukazovania typov premenných a zoznamov funkcií a ja neviem čoho všetkého - musím povedať, že toto všetko mi je absolútne na nič, a myslím si, že ide o nástroje vhodné pre nie veľmi schopných alebo začínajúcich programátorov - mne teda aspoň nerobí žiaden problém pamätať si, čo je daná premenná zač, prípadne si to zistiť tam kde je definovaná - neprogramujem ako prasa, takže to viem zistiť rýchlo a efektívne. Vo vašom prípade to asi bude inak, podľa toho, čo hovoríte.

Inak k tým prirovnaniam. V niektorých situáciách je vhodnejšie IDE, v niektorých efektívny textový editor typu vim. Preto v každej situácii použijeme to, čo sa nám zíde viac. Pripomínate mi človeka, ktorý zistil, že kombinačky sú nesmierne užitočný nástroj - a práve s nimi usilovne zatĺka klince. Kombinačky samozrejme sú užitočný nástroj, ale kladivo je občas predsa len vhodnejšie :) A s editormi je to podobné.

Uff, to som sa zase rozpísal.

Můj názor je takový, že interface, ve kterém nevidím nabídku akcí, a mohu udělat jen to, o čem naprosto přesně vím, jak se dělá, je špatný. A za takový názor mě nikdo platit nemusí, protože k tomu dojde každý, kdo není zdeformovaný tím, že vi/vim používal řadu let.


Souhlasím, že vim má řadu možností. Bohužel má naprosto zoufalý interface, vz výše.

Já jsem četl spoustu článků, a řada z nich byly bláboly (a to nemluvím o zprávičkách na root.cz). Zkuste si představit například word processor typu Word, a to že potřebujete rozepsat adresy na obálky. Protože adresy na obálky běžně nerozepisujete, není problém - najdete v menu nebo helpu co je třeba, a práci uděláte. Pokud to budete dělat každý den, budete už vědět, že použijete CTRL+tohle, Alt+tamto, stisknete dalších pár kláves, a je hotovo. Tak vypadá dobrý interface. Špatný interface vypadá tak, že adresy nerozepíšete, pokud nemáte naučený správný příkaz. Totéž platí ale třeba o naformátování zdrojáku, používání záložek, debuggování aplikace atd.

Ve spoustě případů je dobé rozhraní, které se na vážnou práci nehodí. Když chcete, aby si vaše babička byla schopná vypálit audio CD, nebo sestavit DVD s fotkami z dovolené, musí to být takový interface. Ovšem interface který má MS Office, nebo Visual Studio, je velmi dobře použitelný pro začátečníky i pro profesionály.

Funkce typu ukazování detailů po najetí na proměnnou (datový typ, možnost z kontextového men přejít na deklaraci) jsou velmi užitečné. Umožňují vám soustředit se na jiné, důležitější věci, a co může dělat stroj, necháte na něm. Podobně byste totiž mohl tvrdit, že vám není k ničemu přehled kontaktů v mobilu, protože kdo si není schopen kontakty zapamatovat, neměl by ani mít telefon. Jenže když se nestaráte o pamatování kontaktů, nebo o pamatování schůzek (protože máte plánovací kalendář), můžete se věnovat jiným věcem. Pochopitelně pokud tyhle možnosti nemáte, je třeba tvrdit, že jsou ty hrozny stejně kyselé.

Samozřejmě standalone editor má mnohdy opodstatnění. Například nevidím důvod editovat ve Visual Studiu 3-řádkový konfigurák, protože na to stačí Notepad.

Když nevím, jak se co ve Vimu udělá, použiju Google. To je lepší než menu, které grafická verze Vimu má taky.

Pssst, hlavně mlčet o existenci Creamu, to by nezapadalo do LOova obrazu světa. ;-]

Používat Google místo menu je vtip, nebo to myslíte vážně? I když vzhledem ke kvalitám GVimu je možné, že použít Google je lepší nápad ;)

Vzhledem k tomu, že o možnostech GVimu toho očividně moc nevíte, tak to asi opravdu je lepší nápad.

GVim jsem měl na stroji několik let, a párkrát jsem ho i použil. Jde v principu o terminálovou aplikaci obalenou GUI, a výsledek je velmi podivný. Ale rád se nechám poučit, jestli jsem něco přehlédl.

Milý Laeli, Vim je textový editor, nepoužívá se k tisku na obálky ani neumí vařit kávu. Pokud hledám nějakou funkci, existují v zásadě tři scénáře.

1. Tento editor musím použít z nouze a prakticky nic o něm nevím. Pak si, jak někdo správně poukázal, vystačím s jeho vestavěnou dokumentací, protože pro zeditování konfiguráku apod. toho moc nepotřebuju.

2. Chci použít některou mně dosud neznámou funkci editoru. V tomto případě si ji prostě někde najdu, ať už v menu (typicky práce s okny, tisk, nastavení zvýraznění syntaxe) nebo v dokumentaci nebo pomocí Google. Protože takovou funkci budu zřejmě používat znovu a znovu, zapíšu si ji nebo hned zapamatuju - Vim se člověk učí inkrementálně a zapamatovat si jednu fintu není těžké. Kdybych ji měl hledat pořád dokola v menu, nemělo by to moc smysl.

3. Nelíbí se mi standardní chování, chci si ho změnit. Pak si najdu, jak na to a zapíšu si to nastavení do konfiguračního souboru a už nikdy to nebudu muset znovu hledat, ať už pomocí Google nebo jinak. Konfigurační soubory si migruju ze stroje na stroj. Je to dnadné, je to rychlé, je to univerzální.

Nevidím důvod nad takovýmto způsobem práce ohrnovat nos a neberu nepoučené výtky od člověka, který tento editor nepoužíval alespoň půl roku den co den.

Je mi záhadou, jak chcete v textovém vi/vimu pracovat s menu, které nemá. GUI verze (GVim) menu má, ale program se ovládá podobně příšerně, jako v textové verzi.

Samozřejmě standardní ovládání si můžete změnit i ve Visual Studiu nebo MS Office, stejně jako exportovat a importovat nastavení. Vystavujete se tím ale problémům, jakmile potřebujete používat program někde, kde nemáte svou konfiguraci k dispozici.

Tvrdíte, že výtky má právo vznášet jen ten, kdo pooužívat vi/vim den co den půl roku. Jenže takoví lidé prakticky nejsou. Abyste tak příšerný interface používal půl roku, musíte k tomu být donucen, a toho půl roku se ho den co den učit. Děkuji, nechci - vystačím si se slušným GUI, pohybem kurzoru a prací s myší; zbytek mě aplikace naučí sama.

Samozřejmě jsem mluvil o Gvimu, protože prakticky každý, kdo používá grafické prostředí (99% programátorů nebo i více), používá grafickou verzi.

Pokud nemám někde svou konfiguraci k dispozici (což, pokud budu často chodit od počítače k počítači, bude maximálně u strojů nepřipojených k síti), si můžu nejdůležitější volby nastavit i tak - je jich minimum a pamatuju si je. Furt nevím, proč sem taháte MS Office, dokonce i moje pračka a rychlovarná konvice jde přenastavit, ale to je trochu off topic.

Však já Vás nenutím používat (G)Vim, používejte si, co je Vám blízké. Vim má význam zejména pro lidi, kteří znají jeho přednosti a používají jej pravidelně. Já taky neobcházím lidi a neříkám jim "nepoužívej Eclipse, JEdit, Kate, jedině s Vimem dojdeš spásy". Pokud ale někdo přijde a začne hanět Vim (obecně, ne ve stylu "pro mě je moc složitý, líp se mi pracuje s jiným editorem"), řeknu mu ve vší slušnosti, že je trouba, protože kecá do věcí, kterým nerozumí. A že Vás aplikace něco naučí sama? Jo, naučí, když víte, co od ní můžete čekat. Jinak zůstanete pořád lamičkou, která umí pár procent možností a to ještě neefektivně.

Ano, dobrá GUI aplikace uživatele naučí sama, ale pokud je neschopný, tak aplikace sama nepomůže. Když je člověk neschopný, nepomůže totiž vůbec nic. Ale pointa je v tom, že když je uživatel alespoň trochu schopný, tak se nemusí memorovat stovky příkazů a tisíce klávesových zkratek, přesto může aplikaci používat, a časem ho aplikace naučí ji používat efektivněji. Tohle vi/vim neumí. A o tom to celé je.

Ale sama ho to nenaučí. Jednu dívku jsem nedávno připravoval na pracovní pohovor a chtěl jsem jí pomoci osvěžit základy používání (MS) Office (paradoxní, protože MS Office jsem v zásadě nikdy pořádně nepoužíval), které se měla naučit na střední škole. V životě neviděla polovinu věcí, které jsem jí ukazoval, včetně používání stylů; jsem zvědavý zda a kdy je začne skutečně používat. Pořád ještě ale na tom byla suprově oproti ženským, které si myslí, že na konci každého řádku se musí stisknout Enter, překlep neopravují na místě, ale pomocí Backspace smažou všechno, co za překlepem leží a všechno píšou do jednoho souboru.

S používáním plaintextového editoru je to podobné - pokud se jednou naučíte neefektivní návyky, těžko se přeučují a sama aplikace to za nikoho neudělá.

Nevím, jak vypadá dnešní vim, ale když jsem ho naposledy viděl, bylo to vylepšené vi, a menu jsem fakt nenašel. Možná je menu v textovém vimu novinka?

Otázka je, proč se učit hromadu příkazů a klávesových zkratek? Když potřebuji editovat na úrovni Notepadu, stačí mi použít Notepad, použít myš a kurzorové klávesy. Navíc nesouhlasím, že by práce ve vi/vim byla výrazně efektivnější, než v GUI. Kdybyste si vynaložil setinu úsilí na to, abyste se naučil pracovat s GUI, dosáhl byste velmi dobrých výsledků. Je zvláštní, že někteří lidé nemají problém se naučit 538 příkazů a 1000 klávesových zkratek, ale text v GUI vybírají jen myší, protože neumějí použít ani klávesu CTRL+SHIFT+Left.

Vy zase nečekejte, že bude někdo brát vážně obhajobu interface vi od jeho zaníceného uživatele. Nedostatky (menu, vizuální odezva, obtížné učení) vidí i slepý. Údajnou výhodou je vysoká efektivita, ale jak jsem psal výše, podle mě jde spíše o iluzi.

Řeč byla původně o vi. Ono totiž vi musí být z nějakého obskurního důvodu v každém unixu, kdežto vim, mc apod. nikoliv. Na Linuxu je vi údajně jen převlečeným vimem, ale nemám tu teď testovací systém.

CTRL+SHIFT+Left je pěkná a efektivní metoda. Nepotřebujete znát více, než funkci kurzorových kláves (ta je na nich nakleslená či napsané, což mimochodem u hjkl tvrdit nelze), a funkci modifikátorů Ctrl a Shift. Down - o řádek níže. Shift+kurzorová klávesa - rozšiř označení. Home,Shift+Down - označ ředek včetně znaku konce řádku. Home, Shift+End - označ do konce řádku, bez znaku konce řádku. Ctrl+kurzorová klávesa - posun o více jednotek daným směrem. Ctrl+Shift+Down - rozšiř označení do konce odstavce.

Nepoužívám Eclipse, ale zajímalo by mě, jestli s viPluginem také píšete .PropertyValue namísto tečka-p-tab, jako kolega Rejpal, a také si u toho libujte, jak jste efektivní?

Proboha, ještě že jsem neztratil rok drahoceného času učením vi. Kdybyste ten rok místo patlání se v vi nějak produktivně pracoval, tak byste si vydělal na pěkný sportovní vůz. Ale možná to byla dobrá zábava (mě to tak nepřijde).

ano, Perl považuji za otřesný jazyk. Jeho zastánci samozřejmě tvrdí, že Perl je nejlepší, a dá se v něm napsat cokoliv. Osobně mě jímá hrůza, když vidím kód, který vypadá, jako kdyby se autorovi zasekl shift na klávesnici. Sice jsem napsal v Perlu tisíce řádků, ale k srdci mi nikdy nepřirostl. Jsem zvyklý na výrazně odlišné koncepty. Například když mám string, tak je to string, a nikdo mi do něj nehrabe. Chápu, že když napíšu $s=~ s/a/b/i;, že jde o regexp. Můžeme rovnou přeskočit diskuzi na téma jestli je použítí regexpů vždy a všude dobrý nápad, protože se regexpy špatně učí, špatně píší, a jsou naprosto nečitelné (po půl roce mnohdy i pro autora). Co mě ale šokuje je, když provedu $s=~s/$a/$b/i;. Podle všech svých zvyků považuji "s/$a/$b/i" za string, a protože jde o Perl, tak se $a nahradí za obsah stringu. Ale proč když je ve stringu $a psáno \\abc\ne, tak se to zmrší na \abc[LF]e? Já samozřejmě znám důvod (a vy předpokládám také), ale chci, abyste viděl, že je to naprosto odlišný princip, než jaký používají ADA, BASIC, C, C#, Java, a většina dalších civilizovaných jazyků. Samozřejmě tak pobaví, že $a="\další\obrázky" nevyhodí chybu neplatné escape sekvence, a v pohodě projde. Tomuto typu zhůvěřilostí vděčíte na unixech za problémy s podporou názvů souborů s češtinou, s mezerami atd.

S tím blábolením brzděte, nebo to přeženete. Chceme přece udržet diskuzi slušnou.

"Nepoužívám Eclipse, ale zajímalo by mě, jestli s viPluginem také píšete .PropertyValue namísto tečka-p-tab, jako kolega Rejpal, a také si u toho libujte, jak jste efektivní?"

Už zase lžete zcela viditelně. Dávejte si na to pozor. :-p

To byl pouze předpoklad. Ale řekněte mi, jak píšete .PropertyValue ve vi? Pokud tedy nepoužijete jazyk, kde místo toho napíšete něco jako ~@$$A^&4?

ctl+n?

Samozřejmě chápu, že regexpy jsou pro uživatele unixů dost zásadní. Co nechápete vy je fakt, že se regexpy nadužívají. Pro jednoduché vyhledání nebo replace substringu je daleko lepší použít běžné funkce pro práci se stringy, protože replace(co, za-co), případně s.Contains(co), je na rozdíl od regexpu snadné zapsat i přečíst. Samozřejmě regexy mají jisté využití, a občas je používám v C#. Neštěstím je ale cpát je vždy a všude jako základní prostředek, a to pro obtížnost jejich učení, obtížnost jejich psaní, a jejich nečitelnost.

ja uz jsem na to prisel, vy budete delat asi do marketingu. ti maji taky ve zvyku mluvit chytre o vecech kterym vubec nerozumi.

(zarovicka) tip dne: vite, ze bezne funkce pro praci s retezci jsou take regularni vyrazy.

prejete si dalsi tip dne?

ano, ano!

(zarovicka) tip dne: vite, ze editory jako vim, nepotrebuji rozlisovat jestli se bude pouzivat bezne vyhledavani nebo vyhledavani podle regularniho vyrazu. dokaze tohleto vas pan sponka?

Replace(co,za-co) je regexp? Že jsem si toho nevšiml.

Nemám tu (naštěstí) vim, ale přesto se rád přiučím. Jak vim pozná, jestli vyhledávám regexpem, nebo ne? Když hledám například string [pP]wd, jak ví, jestli má hledat [pW]wd, nebo pwd a Pwd?

MMCH pan Sponka byl výsledek spojení Billa Gatese a Melinda French, se kterou se později Gates oženil. Melinda pracovala v týmu vyvíjejícím rozhraní MS Bob, a pan Sponka byl jediným přeživším výsledkem tohoto projektu. Domnívám se, že Sponka se dostal do Windows a Office právě díky vztahu Melindy a Billa ;)

Velice snadno. Záleží na nastavení proměnné magic. Když mám nastaveno
:set nomagic
najde to [pW]wd, když je nastaveno
:set magic
najde to pwd. Pokud chci při hledání přepnout, dám na začátek \m, resp. \M. A pokud jsem BFU, nastavím si
:nmap / :pro^M
a pak mi to nabídne vyhledávací dialog pro BFU. GVim je úžasně konfigurovatelný a záleží jenom na mně, jak si ho nastavím. Jenom když chci hledat \, musím zadat \\, což je ale pro fanoušky MS systémů určitě velmi přirozené. ;-)

A jak to koresponduje s tvrzením, že "editory jako vim, nepotrebuji rozlisovat jestli se bude pouzivat bezne vyhledavani nebo vyhledavani podle regularniho vyrazu", na které jsem reagoval?
http://www.root.cz/clanky/vifm-spravce-souboru-a-la-vim/nazory/215641/odpovedet/

Už ste počuli pojem "dokumentácia" ? To je ten hypertextový dokument, ktorý si môžete prečítať, a všetky tie funkcie čo nepoznáte tam nájdete. Taktiež tutorial a všetko.

V podstate váš argument je zhruba takýto: nechcem sa NIKDY učiť nič nové, pretože učenie je zlé, áááno? A kto ma núti niečo sa učiť je zlý, áááno? Radšej budem pracovať menej efektívne, ale prosím prosím nenúťte ma naučiť sa niečo nové !!!

Takže když edituji soubor, tak místo kouknutí do menu otevřu dokumentaci, a budu v ní hledat funkci, o které ani nevím, jestli tam je. Až jí najdu, tak si jí zapamatuji, nebo napíšu na papírek-helpáček. Super, skvělé. Máte další nápady, jak učinit práci efektivní? Třeba užíváním husího brku namísto laserové tiskárny?

Nikdo neříká, že by se člověk neměl učit. Ale důležité jsou principy - tedy CO lze udělat, a jak to FUNGUJE (počítač má účty, lze je přidávat, odebírat, měnit hesla, existují doménové účty). Samotné JAK to konkrétně udělat (kliknout sem, napsat příkaz X) je nedůležité. Všimněte si, že na unixech, stejně jako ve vi, nerozlišujete CO a JAK. Ve skutečnosti se jen memorujete JAK, a znalost CO s tím možná časem přijde.

Ehm, a aký že to prosím je rozdiel medzi hľadaním v dokumentácii a hľadaním v menu ? Samozrejme hovorím o -dobrej- dokumentácii, nie o nejakom paškvile typu dokumentácia produktov firmy Microsoft (MSDN je svetlá výnimka, ale aj tá má medzery).

Alebo mi vážne chcete tvrdiť, že pri zakúpení nového elektronického prístroja začnete náhodne stláčať tlačítka s tým, že niečo sa snáď stane, namiesto toho aby ste si prečítali návod na obsluhu ? Zaujímavý prístup, mno ale keď vám to tak vyhovuje ...

To s tým unixom je samozrejme nezmysel, ale to, že unixu absolútne nerozumiete, ste už vraveli veľakrát.

A na záver zopár nadčasových citátov.

"Unix is simple. It just takes a genius to understand its simplicity." – Dennis Ritchie

"Those who don't understand UNIX are condemned to reinvent it, poorly." – Henry Spencer

Takže podle vás je ten proces efektivnější, než "kouknu do menu, a když se tam dívám potřetí, tak si zapamatuji klávesu"? A je také pohodlnější?

Když jsme u toho, proč si myslíte, že vi nepoužívá prakticky nikdo? Nepoužívá ho téměř nikdo mimo platformu unix, a ani unixáci, kterým ovládání vi nacpali ve škole do hlavy násilím, se k němu mohdy nehlásí. Proč jste naprostou výjimkou, když vám jeho ovládání vyhovuje?

Máte nějaké konkrétní poznatky o efektivitě práce s vi? Jak jsem psal, někteří lidé nemají problém se naučit stovky příkazů vi, ale nenaučili se slušně zacházet s GUI.

A mohu se zeptat, proč je efektivnější otevírat dokumentaci, něco v ní hledat, a memorovat se to (nebo nedej bože používat papírek helpáček), než se prostě podívat v menu?

Statistiky používání editorů jsem nehledal. Ono stačí se podívat okolo sebe. I když pokud se díváte po tom 1% uživatelů Linuxu, tak možná vidíte něco jiného, než ostatní lidé.

Já nejsem líný se učit. Jen si myslím, že jednoduché věci se mají dělat jednoduše, a mám nechuť se učit zbytečnosti.

Jako příklad bych uvedl přenosné telefony Siemens (tuším první série Gigaset?). Ty kdysi měly B/W LCD display s klasickými 8-segmentovými číslicemi. Když jste chtěl telefon zamknout, odemknout, změnit heslo, zapnout přesměrování hovorů apod., "prostě" jste namačkal něco typu "klíč-hvězdička-883141", a ono to něco udělalo. Kupodivu se tyhle telefony moc neprodávaly. Když Siemens převzal klasické ovládání mobilů, tedy s menu ze kterého se dá vybrat, byla to velká změna. Kupodivu můžete pracovat podobně jako s původním ovládáním (jako na většině mobilů) - stisknete "menu-3512", a je hotovo. Rozdíl je v tom, že když nevíte, jak danou věci uděláte, najdete jí v menu. Když vás bude trápit rychlost, podíváte se na displayi na zkratku, a příště jí použijete.
Vy byste ovšem používal to původní ovládání, přestože je vysloveně debilní, kriptické, a nevhodné k používání člověkem. Řekněte mi: proč proboha? Má to smysl? Možná si pak připadáte, že jste se něco užitečného naučil. Ale není lepší investovat úsilí do něčeho smysluplného?

Ja si tiež myslím, že jednoduché veci sa majú robiť jednoducho ... len sa zdá, že sa nezhodneme na tom, čo pojem jednoducho znamená ... on problém s GUI vôbec nie je to, čo píšete, klávesové skratky a podobné veci sa naučia ľahko - problém s GUI je, že robí jednoduché veci jednoduchšími ... a zložitejšie veci zložitejšími. To mi nepripadá ako dobrý kompromis.

Vi/vim samozrejme šípky používať dokáže - zistite si fakty.

Čo robí vi mocným je jeho flexibilnosť a rozšíriteľnosť spôsobmi, aké by v GUI boli nemožné. Veci ako hľadanie v histórii použitých príkazov aj s parametrami, opakovanie a reťazenie príkazov, a tak ďalej a tak ďalej. Je toho dosť.

Ale pokiaľ trváte na tom, že program je použiteľný jedine v prípade, že ho dokáže pochopiť cvičený šimpanz, tak môžem akurát povedať, že vás ľutujem.

Inak tie vaše výlevy o perle sú dosť úsmevné - dobrý programátor samozrejme napíše čitateľný a udržiavateľný kód v takmer čomkoľvek, čo prekvapivo zahŕňa aj perl - je ale zjavné, že to váš prípad nebude. Osobne keby som bol mizerný programátor by som to teda asi do sveta nevykrikoval, mno ale každému čo jeho jest.

Počítače umí dělat spoustu věcí. Ty věci, které se dělají často, se musí dělat jednoduše. A o tom je UI.

Netvrdil jsem, že vi/vim neumí používat šipky. Samozřejmě ten předpotopní terminálový systém občas vede k tomu, že šipky nefungují (aby ne, se stovkami typů terminálů), a pak se hjkl hodí. Někteří hardcode uživatelé vi tvrdí, že je přehmatávání až na kurzorové klávesy hrozně zdržuje :)

O cvičených šimpanzích viz první odstavec. Jednoduché věci se dělají jednoduše. Popisoval jsem jinde ten interface přenosných telefonů Siemens. Co si o tom myslíte vy?

Já nejsem programátor, a v Perlu píšu pouze v sebeobraně. Ovšem podle vás je mizerný programátor každý, komu se nelíbí Perl, že? Pletete si to s něčím jiným. Já nesouhlasím s tím klasickým tvrzením, že unixy jsou übercool a zábavné. Jednoduché věci jednoduše, počítač jako mikrovlnka či mobil. Jiní lidé naopak tvrdí, že počítače nemají ovládat cvičení šimpanzi, a kvůli pitomé editaci textovách souborů se člověk má naučit stovky příkazů, tisíce klávesových zkratek, a ztratit minimálně měsíce času. Děkuji, nechci - mám pro čas lepší využití.

Já nejsem programátor, a v Perlu píšu pouze v sebeobraně.

huh, aha.

zasadni otazka, co vlastne jste?

mám pro čas lepší využití

fakticky?! nelzete?! ...nebo vedete tak nudny zivot, ze prudeni v diskuzich je to nejlepsi vyuziti vaseho casu, ktereho jste schopen?

Co jsem, to si s dovolením nechám pro sebe.

Delší diskuze na rootu jsou spíše důslekem toho, že se občas nechám unést. I když dnes se trochu nudím. V Bruselu není moc zábavy. Naštěstí jsem tu jen na skok za kolegy.

Ve věci využit času jsem měl na mysli samozřejmě čas pracovní. Přemýšlím, jestli bych si raději uřízl ruku, než se učil vi v době svého odpočinku. Nakonec si říkám, že bych se raději učil vi, než obětoval ruku.

Zdravím Vás, pane Špidlo. :-D

Jen to ne :). Mimochodem je zajímavé pozorovat české evropské úředníky na cestě do práce. Někteří jsou schopní se porvat kvůli upgradu do business class. Naštěstí už s nimi nelétám.

Zato já si všiml řady problémů. Například mezery v názvech řada skriptů nezpracuje

Tento problém neznám, asi vám ty skripty píší nějaká děcka?

Podobně s češtinou v názvech souborů, která působí tolik problémů, že jí uživatelé unixů raději nepoužívají

Lež jako věž :D

A sám můžete vidět, že řada uživatelů unixů dodnes píše příspvěky a maily bez diakritiky

Asi to jsou programátoři, na rozdíl od mraku sekretářek na Windows.

Takže ano, i já mám tyhle problémy.

Mnohem větší než tušíte...

Tuhle jsem zkoušel po létech něco na Windows, musel jsem spustit jeden "konzolový" program, a ono tam nefungovalo ani "cd Dokumenty". Šílený :D

Jistě, Oracle píšou malé děti. A čeština v názvech souborů? Před časem se to tu diskutovalo, a převažující názor uživatelů unixů byl ten, že používání mezer a diakritiky v názvech souborů je "prasárna", protože to působí řadu problémů.

A že by to mohlo být třeba tím, že si uživatelé Unixu (v průměru technicky zdatnější než průměrný uživatel Windows) jsou vědomi, jaké problémy to může například dělat některým síťovým protokolům při přenosu, Vás nenapadlo? Kdo píše Oracle, to bych se radši neptal. Asi by to byla podobná odpověď, jako v případě SAPu, Windows a spol.

Já měl za to, že FS povoluje názvy souborů s mezerami, i s diakritikou. A opravdu mě nenapadá, který síťový protokol by měl mít problémy s dlouhými názvy.

Kdo píše Oracle jsem řešit nechtěl. To jen kolega tvrdil, že skripty které, nepracují s dlouhými názvy, píší děti.

S dlouhými názvy asi žádný, ale o tom jsem přeci nemluvil, že? ;]

Dlouhé názvy jsou taková ta věc delší než 8.3, a s národními znaky. Jednak předpokládám, že znáte běžnou terminologii, a potom to bylo zjevné z kontextu.

No tohle rozhodne neni bezna unixova terminologie :-).

Co se tyce prenosu znaku s diakritikou, tak treba FTP ci starsi (a stale prevazne rozsirene) verze SFTP. Ty snad nedefinuji kodovani prenasenych souboru, takze pri prenosu mezi ruznymi systemy muze dojit k poskozeni diakritiky.

A co se tyka chyb v implementacich, tech je pozehnane. Napriklad z MS Outlook Expressu me stale prichazeji maily, ktere maji chybu v implementaci MIME encoded words a posilaji nevalidne kodovana jmena priloh, pokud ve jmenu souboru (prilohy) byla mezera a diakritika.

Ono vzhledem k tomu, že kódování názvů souborů na unixech není dané ani na lokálním disku, tak je nějaké (S)FTP už celkem nuda.

Pokud jsem si všiml, tak dlouhé názvy v mailech z Outlook Express jsou ve skutečnosti problémem Mozilla Mailu, nebo čeho. Dost divoce se to diskutovalo tady i na abclinuxu. Ale moc jsdem to nesledoval, klidně mě opravte.

Opravuji, nejedna se presne o chybu v MIME encoded words, ale v chybnem pouziti parametru u Content-Disposition.

Priklad z mailu posleneho z Outlook Express:

Content-Disposition: attachment; filename="=?iso-8859-2?Q?Provoz_o_V=E1noc=EDch.doc?="

Tedy v atributu filename je hodnota zakodovana pomoci MIME encoded word.

RFC 2231 (z roku 1997 !)uvadi:

(2) MIME headers, like the RFC 822 headers they often
appear in, are limited to 7bit US-ASCII, and the
encoded-word mechanisms of RFC 2047 are not available
to parameter values. This makes it impossible to have
parameter values in character sets other than US-ASCII
without specifying some sort of private per-parameter
encoding.


A definuje takove kodovani (v sekci 4), podle ktereho by to melo vypadat takto:

Content-Disposition: attachment; filename*=iso-8859-1''Provoz%20o%20v%E1noc%EDch%2Edoc

Outlook Express neimplementuje RFC2231 pro odesílání příloh. Zřejmě začali psát SW ještě před rokem 1997 :)

Nejenom, ze neimplementuje RFC 2231, ale to, co dela se jmeny s diakritikou, zcela evidentne porusuje RFC 2047 5/(3).

Coz tedy znamena, ze Outlook Express (asi prevazujici mail klient pro Windows) neumoznuje korektni posilani souboru s diakritikou ve jmene. Neni to jasna ukazka toho, ze (z pohledu uzivatele) davat do jmen diakritiku je zbytecne koledovani si o problemy?

Implementace RFC2231 přece není povinná. Navíc Outlook Express je už 4 roky mrtvý produkt. Pokračovatelem jsou Windows Live Mail (v XP) a Windows Mail (ve Vistě).

Nemám čas to příliš zkoumat, ale je pravděpodobné, že RFC 2047 je v OE implementováno a porušeno (alternativně není implementováno, a RFC 822 ani 2183 porušeno není). Otázka je, koho to mrzí, když bylo/je klientů s OE ve stovkách milionů, a tedy o tom každý ví. Samozřejmě se tak každý může naučit názvy parsovat. Není to první ani poslední standard, který autoři SW porušují (a nad důvody by se dalo jistě diskutovat).

Dávat diskritiku do jmen souborů není na Windows problém. Mail poslaný z Windows na Windows ty názvy zachová, a naprostá většina ostatních klientů dávno ví, co jak OE posílá názvy souborů. Navíc zachování názvů souborů ani není v RFC vztahujících se k MIME požadováno - filename je pouze doporučením pro cílový systém, see RFC 2183 chapter 2.3.

Za daleko větší problém považuji fakt, že na unixech není zachování korektního názvu souboru zaručeno ani na lokálním systému, protože se názvy v různých kódováním mohou volně míchat na FS. To když nehovoříme o bugách/buzích/bugěch (proboha) ve skriptech i aplikacích.

"Samozřejmě se tak každý může naučit názvy parsovat. ... Mail poslaný z Windows na Windows ty názvy zachová, a naprostá většina ostatních klientů dávno ví, co jak OE posílá názvy souborů." Tzv. "standard de violentia"? :-D A proč teda IETF máme?

Za daleko větší problém považuji fakt, že na unixech není zachování korektního názvu souboru zaručeno ani na lokálním systému, protože se názvy v různých kódováním mohou volně míchat na FS."

Že by PEBKAC? Pokud mi nějaký program uloží na disk soubor s non-UTF-8 názvem, tak jakmile opadne moje počáteční chuť zabít jeho autora tupým předmětem, poletí ten program vesele z disku. Zatím se tak ale nestalo. S mapováním názvů z oddílů Windows tak nějak problémy taky nemám.

Řekněme stadard de facto.

Starší SW není psaný s podporou Unicode. Těžko tedy může psát názvy souborů v UTF-8 (až na výjimky kde daný SW názvy v UTF-8 můžete nakrmit - v GUI to ale nepřipadá v úvahu).

Starší SW ve Windows taky nemusí být psaný s podporou Unicode, nebo aspoň ještě před pár lety jsme v práci s některými aplikacemi měli problémy. Přinejmenším v případě GNU softwaru je ale podpora UTF-8 doplňována, takže zase *tak* krizově bych to neviděl. Nové aplikace si takhle už nikdo napsat nedovolí, protože by se mu pak v komunitě právem smáli. :-)

Samozřejmě starší SW psaý pro Windows nemusí mít podporu Unicode. Rozdíl je v tom, jak je zajištěná zpětná kompatibilita. Ve Windows máte názvy souborů na disku vždy v Unicode. Total Commander psaný bez podpory Unicode (stejně jako jakákoliv obdobná aplikace) bude schopen vytvořit soubor s češtinou v názvu, a ta bude vidět ze všech ostatních aplikací korektně. Obdobně taková aplikace uvidí zcela korektně soubory, které mají češtinu v názvu. To vše proto, že volání starých aplikací jsou překládána z code page do Unicode. Zavoláte CreateFileA, předáte pointer na char; systém to přeloží na řetězec z wcharů, a zavolá CreateFileW. Tomu se říká kompatibilita. Naopak unixech se názvy v různých kódováním mohou volně míchat na FS.

> že na unixech není zachování korektního názvu souboru zaručeno ani na lokálním systému

Ale je, z filesystemu vyzvednes presne takovy nazev, jaky jsi tam ulozil.

> protože se názvy v různých kódováním mohou volně míchat na FS.

Samozrejme ze muzou. Kdyz jeden uzivatel preferuje jedno kodovani a jiny uzivatel jine. Proc by jim mel operacni system spolecne kodovani vnucovat?

Operační systém možná ne, ale já jako admin to udělám velice rád. :-> BOFH! :D

Jenže já bych byl radši, kdybych v aplikaci A viděl názvy souborů tak, jak jsem je v aplikaci B zapsal. Ono je to tak nějak lepší pro manipulaci se soubory, a pro jejich přenos. Další otázkou potom je, co udělají UTF-8 aplikace (Qt, GTK), když narazí na neplatnou UTF-8 sekvenci. GTK by to možná mohlo rozdýchat (string zpracuje jak byl), Qt těžko (pokusí se o převod stringu do UTF-16, což neprojde, a pak nevím).

Copak uživatelé. Je to spíše o starém SW, který neoperuje v Unicode. Nakonec si vzpomeňte, že ještě v druhé polovině devadesátých let se na Linuxu řešila čeština a podpora 8859-* code pages. Unicode se začal řešit někdy před pár lety. Ale srovnání řešení situace na Windows a na unixech tu už několikrát bylo. Unixy mají holt podporu Unicode řešenou špatně.

AUX a další jsou rezervovaná jména. Zkuste si uložit dokument v Notepadu pod jménem aux, a on vám vysvětlí, že jde o rezervované jméno zařízení. Když jsme u toho, jména zařízení jsou pozůstatkem unixových konceptů.

10 let staré Windows 98? Já ve Windows 95 ukládal do adresáře tisíce souborů, a problém jsem nepostřehl. Ale bavít se dnes o 10+ let starém systému je naprosto mimo.

Kolik je tech rezervovanych jmen ?

Chapu ze nemuzu vytvorit /dev/aux, ale klidne vytvorim /tmp/aux /Aux /aUx atd.

1)
Na M$Win nevytvorim celou neznamou mnozinu souboru :-), protoze soudruzi z Redmontu
maji "dev" asi vsude :-)))

2)
Je mi jedno jak jsou 98 stare. Je to v provozu, potreboval jsem seznam souboru, ktery jsem dostal neuplny. Potreboval jsem ho cely.

Takze na zaklade 1) a 2):
M$WIN LIBOVOLNE VERZE NEUMI ZAKLADNI PRACI SE SOUBORY
tecka.

1) Snad umíte hledat v dokumentaci, ne? CON, PRN, AUX, NUL, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, and LPT9
http://msdn.microsoft.com/en-us/library/aa365247.aspx

2) Mě je jedno, co jste před 10 lety údajně potřeboval, a co tehdejší Windows údajně udělaly. Mám vám vyprávět, jak jsem před 10 lety zkoušel rozchodit USB tiskárnu pod Linuxem?

1) Na tom odkazu je pekne zhrnuto co to vsechno (oficielne) neumi, diky.

No dost slabucky souborovy system. Obcas se hodi i linky.

2) Ten system je v provozu ted, s temi 10 lety si zacal ty.

Nemam cas objevovat, zaplatovat, nedej boze zkouset jine verze WIN.
2.1) ten stroj by to neutahl
2.2) aplikace na jine verzi by nemusela vubec jet
2.3) ten system tak jak je vicemene funguje - az na to, ze jsem si nemohl stahnout
seznam souboru s jednoho adresare za pomoci nastroju M$

Tipuji na chybu v implementaci dosovske utility "dir".

No nic tak tam s USB nabootuju nejaky opravdovy OS a ten seznam dostanu.

1) Omezení se netýká file systému, ale operačního systému. Toto omezení je zavedeno z důvodu zpětné kompatibility. Jinak NTFS umí být case sensitive, umí hardlinky, a umí jakékoliv názvy souborů (třeba s hvězdičkou v názvu souboru). Vrstva Win32 je case insensitive, hardlinky umí až recentně, a názvy souborů omezuje popsaným způsobem.

2) Vy máte živý systém s Windows 98? Pěkné :). Bohužel dávno nemám ani virtuální stroj s Windows 9x, takže ani neověřím, jestli popsaný problém existuje.
Ano, přečíst disk z jiného OS je celkem dobrý nápad. Pokud má stroj USB port, nebo (funkční) CD mechaniku. Upozorňuji, že ukládat na FA více než 100 souborů do jednoho adresáře přináší problémy s výkonem, a jde tedy o špatný design aplikace.

No to je veselé. :-) Takže Unix tzv. "neumí" (samozřejmě umí) dlouhé, mezerovité a diakritické názvy souborů, které uživatel chce, zato ve Windows je údajně vše v pořádku, ale nakonec se dozvíme o tuctu "rezervovaných" názvů. A ještě svede se to na Unix, který zřejmě může za všechno špatné na Windows - "jména zařízení jsou pozůstatkem unixových konceptů" - přitom Unix nikdy nic podobného nedělal, názvy zařízení jsou úplně normální názvy souborů v jednom adresáři a nijak neovlivňují to, co si můžu udělat v domovském adresáři. Upřímně obdivuji Váš žaludek, aby ustál takovýhle doublethink, musí být skutečně medvědí. :]

Jak jsem psal dříve, dlouhé názvy souborů (mezery a diakritika) na unixech působí řadu problémů. Typicky na nich havarují skripty, ve kterých autoři zapomněli takové názvy ošetřit. Jestli vy takovou zkušenost nemáte, tak já ano. A když se podíváte na zdejší diskuze, tak se dozvíte, že dlouhé názvy jsou prasárna, kterou slusny unixak prece nepouziva.

Rezerované názvy zařízení prostě existují, těžko s tím něco udělám :). Koncept souborového interface pro zařízení je původem z unixů. A můžete si všimnout, že DOS neměl žádný adresář s device files, nakonec na začátku snad ani podporu adresářů.

> Jak jsem psal dříve, dlouhé názvy souborů (mezery a diakritika) na unixech působí řadu problémů.

Zjevne je, ze nazvy souboru s mezearam a diakritikou pusobi problemy vsude. At uz jde o neosetrene shellove skripty v Unixu, nebo o programy pouzivajici ANSI rozhrani ve Windows (treba Total Commander).

Jediny rozdil je v tom, ze dle Laela Ophira je neosetreny skript v Oracle jasna ukazka, jak to v Unixu nefunguje, zatimco druhy pripad je pouze bug v programu a ve Windows vsechno funguje idealne.

Bohužel v případě Linuxu nastává tento problém už s řadou skriptů či aplikací, které jsou součástí distra.

Mezery v názvech souborů nejsou ve Windows problém, snad s výjimkou Oracle coby portu z unixu. Teď jsem počítal dokumenty obsahující mezeru v názvu, a mám jich ve svém home 1189 kousků. Nakonec dokumenty mám v adresáři "My Documents", a programy v "Program Files". Kdyby s tím byl problém, asi bych si všiml :)

Diakritika není problém ani v ANSI aplikacích, například v Total Commanderu. Výjimkou jsou znaky mimo primární znakovou sadu systému (tedy v ANSI1250 prostředí třeba azbuka). Total Commander je bohužel aplikace psaná idiotem, který si existenci Unicode ve Windows řady NT neuvědomil ani po 15 letech. Ale co chcete od člověka, který ukládal nastavení do adresáře, kde má jeho aplikace binárky :(. Bohužel idiotům nelze zabránit v psaní aplikací; už myšlenku certifikace driverů považuje spousta čtenářů root.cz div ne za fašismus. Upozorňuji, že TC není součástí Windows.

> A když se podíváte na zdejší diskuze, tak se dozvíte, že dlouhé názvy jsou prasárna, kterou slusny unixak prece nepouziva.

Informovany uzivatel vi, ze bugy tohoho charakteru jsou vsude (viz treba ty prilohy v MS Outlook Express, ci soubory v Total Commanderu) a usetri si praci tim, ze soubor pojmenuje bez diakritiky a s _ misto mezer. Neinformovany (nebo extremne tvrdohlavy) uzivatel to tak nedela, a pak se rozciluje nad zabugovanymi programy.

Viz zde: http://www.root.cz/clanky/vifm-spravce-souboru-a-la-vim/nazory/216216/

Cim musi clovek intoxikovat svuj organismus, aby dokazal vyplodit podobnej blabol?

Srovnavat +/- 20 rezervovanych vyrazu s tremi rozsahlymi mnozinami na to snad musi mit clovek vskutku pokrivene vnimani reality.

Nejsíš Windowsama, tento "systém" se základním věcem teprve učí, ale člověka dovede otravit docela rychle.

Naštěstí se vi(m) a podobným excesům dá na unixech vyhnout.