A když si omylem smažete data, nezapomeňte si smazat i zálohu

Odešel mi počítač. Tedy – čistě technicky – on vlastně vůbec neodešel. Odešel totiž jen jeho pevný disk. Počítač (notebook, abych byl přesný) je jinak v poměrně dobrém stavu. Pomineme-li skutečnost, že některé klávesy vypadávají a jiné vydávají zvuk jak psací stroj. A také USB konektory jsou za ty roky docela vyviklané. A pochopitelně, baterka už slouží spíš jenom jako těžítko, aby notebook neklouzal po stole. A obrazovka má rozlišení menší, než podprůměrný smartphone.

Zkrátka a dobře, notebook je spíše jen zastaralý morálně, než že by byl reálně nefunkční. A že mi po téměř 10 letech přišel pomalý, bylo zapříčiněno z naprosto drtivé většiny pouze a jenom tím, že pro mě je zcela běžné mít trvale otevřený prohlížeč s desítkami záložek/stránek (tabů, rozumíme si?). A takové množství stránek s logicky nemá šanci vejít najednou do RAM, a tudíž si systém většinu z nich musí trval odkládat na pevný disk. A nasávat stovky megabytů dat z HDD (ano HDD, notebook je 10 let starý, vzpomínáte?) při každém přepnutí záložky pak prostě trvá. (A pokud člověk kromě prohlížeče otevřel i něco jiného, často se do paměti nevešel web ani jeden, a dlouhé čekání tak nastávalo pokaždé při přepnutí okna.)

Obrazovka notebooku s rozepsaným článkem
Notebook ještě zvládl napsání tohoto článku, i když v značně improvizovaných podmínkách

Když jsem jej, z důvodů, které budu vysvětlovat v následujících odstavcích, nastartoval z flash disku (pomocí live instalačního disku distribuce xubuntu), ukázalo se, že vlastně šlape celkem slušně. Nemít paměť trvale obsazenou desítkami prohlížečových záložek, a nutnost téměř trvale přelévat stovky megabytů mezi pamětí a diskem, vlastně vyřešilo ten hlavní problém s výkonem. Dokonce jsem byl vyloženě překvapen, odhlášení a znovupřihlášení (které si vyžádala nějaká změna nastavení), celé proběhlo jen v mžiku oka (včetně zavření a znovuotevření spuštěných aplikací).

Když on vlastně při zavření prohlížeče vůbec nebyl pomalý. Chvíli mi fakt bylo líto, že bude muset odejít do křemíkového nebe.

Ale já se dnes nechci chlubit tím, jak jsou operační systémy s linuxovým jádrem skvělé, svižné a nenáročné. To konekoneckonců velmi výstižně zvládl sám jeho autor. Chtěl bych vám tady povědět příběh o zálohování, o strachu z jeho nedostatečnosti a tom, jaké fatální následky to nakonec vlastně může mít. Jak již totiž bylo zmíněno, odešel mi disk, a to je přesně ten moment, kdy se člověk modlí k bohu Gigovi, tedy patronovi všech záloh.

Správce úloh: Procesor: 3%, Paměť: 35%, SWAP: 0%.
Při otevření jen několika málo stránek v prohlížeči si najednou počítač brumlá na volnoběh.

Zálohuješ? Ano, jistě, samozřejmě, …

Trocha teorie na úvod: zálohování má jedno jedinné pravidlo: Zálohujete nedostatečně. Nezálohujete dostatečně často, nezálohujete všechno potřebné, nemáte zálohy záloh a jejich zálohy (a nebo jejich zálohy) a další hromada neduhů, která by vydala na samosatný článek. To na úvod víme asi tak všichni.

Já, člověk, který obecně nerad kupuje jak hardware, tak i software, a tudíž vlastním pouze jeden externí disk a žádné placené cloudové uložiště, mám tedy poměrně svázané ruce se zálohováním svého počítače. Moje zálohování tak vlastně obnáší jen čas od času disk připojit a spustit skriptík, který rsync -cuje vybrané složky z počítače na něj. (Pochopitelně, některé kriticky důležité věci mám i porůznu v cloudech, ale to je spíše důsledek než záměr.) A to s tím, že tuto zálohu jsem prováděl obzvláště, když jsem věděl, že mám na disku provedené větší množství změn (např. vytřídění fotek, dokončení nějakého mého projektíku a podob.).

A pak to přišlo. Skoro

Tento systém fungoval poměrně bezproblémově (to česky řečeno znamená, že nebyla potřeba ze zálohy nic obnovovat, takže systém, který je jinak poměrně nedostatečný, neměl příležitost své slabiny ukázat světu). Změna nastala někdy před Vánoci, když se mi, poté, co pár dní pár věcí v počítači nefungovalo úplně jak mělo, objevila v konzoli při některé z činností hláška: „File system is read only“.

Bylo mi celkem jasné o co jde: Disk, nejslabší článek řetězu mého počítače, začíná selhávat. Poučen minulostí jsem systém restartoval a nastartoval z flashky výše zmíněné xubuntu. Tím pádem je možné celý disk „odmountovat“ (softwarově odpojit) a provést na něm kontrolu a opravu chyb. A samozřejmě, ještě předtím zazálohování – pro případ, že by se nezadařilo.

Takovou zvláštní vlastností linuxových systémů je, že vy si klidně můžete smazat celý disk (pro zájemce: sudo rm -rf /) a počítač poměrně vesele poběží dál. Takže se vám klidně může stát, že vám odejde disk a vy to zjistíte až po pár dnech.

Oprava disku proběhla celkem bez problémů. A jak se ukázalo, problém se s periodou několika málo týdnů vracel zpět. To znamenalo přesně dvě věci: Zaprvé, přeinstalování softwarových balíků, které se při opravě poškodily, jsem si zautomatizoval do jednoduchého skriptíku, takže oprava disku se posléze stala celkem rutinnou („restartuj, spusť jeden příkaz, restartuj, spusť druhý příkaz, přihlaš se a funguj jak normálně“). A zadruhé: začal jsem uvažovat o koupi nového počítače.

Ale pak to spadlo úplně

Chtěl jsem si proto rychle dokončit pár rozpracovaných věcí a ze stavu „uvažuji o koupi nového počítače“ se překlopit do stavu „jsem rozhodnutý koupit si nový počítač“ a následně „kupuji si nový počítač“. A stejně jako v Jak jsem (nena)psal bakalářku: To se nakonec nikdy nestalo.

A tak jsem, konkrétně (a zcela přesně) před provedením git commit opět uviděl onu hlášku o uzamčení souborového systému. Tentokrát se oprava nespokojila s prostým proběhnutím a odstraněním nepoužívaných inod. Nyní se na disku objevilo dokonce i několik konfliktů (tj. jeden soubor byl zapsán na dvě místa či naopak – jedno místo na disku se tváří, že obsahuje vícero souborů).

A zde začíná série špatných rozhodnutí a chyb, která vyústila ve ztrátu značného množství dat.

Proč v reálném životě sakra nefunguje Ctrl+Z?

Vystrašen tím, že můj systém (a data v něm) teď aktuálně mohou vypadat asi jako slepenec Arnoldů J. Rimmerů z nepovedené snahy o vytvoření ohromného množství kopií sebe sama, rozhodl jsem se zůstat nastartovaný v systému z flashky, abych zabránil dalším škodám a provést finální zálohu. Vlastně se tím připravit na to, že disk může kdykoliv odejít. (Jinými slovy, přestat jej úplně používat, aby nebylo nic, co bych jeho nečekaným selháním ztratil.)

Nicméně, při dalším průzkumu se ukázalo, že to byla poměrně zbytečná obava; vetšina konfliktů znamenala pouze a jen to, že číslo inod některých souborů se nastavil na nulu či jedničku, a soubory, kterých se to týkalo byly vesměs buďto jen manuálové soubory a nebo soubory v koši. (To se poté později potvrdilo: po restartu zpět do „mého“ systému na disku, naběhl bez sebemenších problémů, dokonce i bez potřeby opravovat poškozené balíky.)

Fantóm Opery

Každopádně, tohoto krizového režimu jsem využil k tomu, abych provedl rozsáhlejší zálohu obsahu disku. Bohužel, jedny z nejdůležitějších dat, která jsem chtěl zazálohovat, byly právě ty ony otevřené (a v poslední době navštívené) stránky v prohlížeči, které dozajista nemalou měrou přispěly k uspíšenému konci životnosti disku. A to je věc, která prostým překopírováním souborů prostě udělat nejde. (I když, je fakt, že kdybych si do nového počítače – či jen do xubuntu – překopíroval celou složku s daty prohlížeče a prohlížeč spustil, je docela vysoká šance, že by data načetl jako svá vlastní a můj export by bylo možné provést i tímto způsobem. Škoda, že mě to nenapadlo dřív…)

Před nějakou dobou jsem si na to vytvořil poměrně roztomilý nástroj (podrobně je popsán v: Export historie prohlížeče: proč to dělat jednoduše, když to jde složitě?). Jenže pro jeho využití je potřeba mít před sebou onen prohlížeč otevřený. A to v době, kdy jsem se připravoval na to, že disk nepřežije ani start systému, natož pak spuštění prohlížeče s desítkami záložek, nějaká snaha o provedení exportu standardní cestou nepřipadala vůbec v úvahu.

„Už dlouho jsem si neexportoval historii prohlížeče. O víkendu to musím udělat.“

já, přesně dva dny před tímto incidentem

Agent s povolením klikat

Nicméně, abych si ušetřil alespoň restart systému, vymyslel jsem trik: V systému, který běží z flashky, si vytvořím nového uživatele, ale řeknu mu, že jeho domovský adresář je totožný s domovským adresářem mého uživatele v počítači. Díky tomu se tak budu moct normálně přihlásit pod tímto novým uživatelem a pracovat s mými daty v počítači, jako byly mé vlastní – a přitom bez potřeby restartu, který by disk mohl dorazit.

Pro jistotu jsem se nového uživatele rozhodl založit přes grafické nabídky. Vypadalo to, že jde o čas a na experimenty s příkazovou řádkou nebyl čas a riziko překlepů a chyb z nepozornosti veliké. A právě proto jsem přesně jednu takovou udělal.

Jedno ze základních pravidel IT říká, že pokud nějaká činnosti či operace proběhla moc rychle, je to pozdeřelé a většinou to nevěstí nic dobrého. Většinou. Asi tak v 0,1% případů to totiž bývá přesně naopak.

Když jsem totiž zvolil domovský adresář nového uživatele, vyskočil na mě dialog o pár odstavcích, který mě varoval, že tento adresář už existuje, jestli ho opravdu chci nastavit a bla bla bla… Dialog jsem jen letmo prolétl očima a zvolil „Ano“. Poté se objevilo obligátní „vyčkejte, probíhá provádění změn“. Dávalo mi to naprostý smysl! Změnil jsem uživatele, který vlastní statisíce souborů, takže se u každého z nich musí tato informace zapsat, přece. Ne?

Ne, ne. Ten dialog se mě snažil varovat, že pokud chci takto nastavit složku novému uživateli, musí být prázdná. A pokud není, bude prázdnou učiněna. (Přiznávám, kdybych se nad tím zastavil a ten dialog si 3x po sobě přečetl, nejspíš by mi došlo, jakou možnost zvolit. Vždyť ale on ten dialog vyloženě zmiňuje „pokud se bojíte ztráty dat, zvolte raději …“, bohužel měl na mysli jiná data než já.)

Dialog varující před smazáním souborů.
Dialog varující před smazáním souborů. A jak byste jej pochopili vy?

A tak se stalo, co se stalo. Domovský adresář na mém pevném disku, tedy všechny mé soubory, byly do posledního smazány. To samo o sobě je průšvih. Existují ovšem způsoby, jak jej zvrátit. Tady se asi objevila další chyba: kdybych byl býval uživatele zakládal přes příkazovou řádku, pravděpodobně by se kromě vyprázdnění jeho domovského adresáře nevytvářely žádné další soubory. Bohužel, vytvořením uživatele přes grafické prostředí automaticky vede k vytvoření základního nastavení (vytvoření složky pro Plochu, Dokumenty a podob.). Už jen to o další malý kousek snížilo šanci, že se historii prohlížeče (ale spolu s tím spoutu dalších dat, o kterých jsem neměl ani ponětí, že bych si je měl zazálohovat) už nikdy nepodaří zachránit.

Nepropadejte panice

Zde jsem ovšem zpanikařil. Vidina toho, že všechna moje data už neexistují v mém počítači, a jedinné místo, kde jsou k nalezení, je 10 let starý externí disk, mě poměrně vyděsila a tak jsem prakticky okamžitě po tomto zjištění rozhodl začít urychleně zálohu obnovovat s vidinou: „když už jsem si smazal všechno nezazálohované, velmi nerad bych přišel i o to zazálohované“.

Že jsi celou tu dobu měl někde na novém, svižném několika terrabytovém disku několikanásobně duplikovanou bitovou kopii celého rozbitého disku, pro případ, že se něco semele, a tento příběh je jen takové veselé povídání o nezávazném experimentování, že? A nebo snad ne?

Zde se asi pro kontext hodí doplnit střípek informace, že při finálním zálohování došlo k nějaké, poměrně hrubé závadě (osobně typoval bych zaškbrtnutí v napájení disku způsobeného vadným USB konektorem či kabelem), která vyústila v to, že se – nyní už i externí – disk poškodil. A při snaze jej opravit mi systém (resp. fsck) řekl něco na způsob: „Sorry jako, tak tohle nedám. Tahle chyba je tak fatální, že to musíš připojit k nějakýmu počítači s Windows a nechat to opravit je“.

Naštěstí se mi podařilo nějaký počítač s Windows oživit a disk celkem lehce opravit. Ale jistě pochopíte, že to na stresu a strachu ze ztráty dat rozhodně neubralo. Ba naopak.

A tak jsem tedy spustil kopírování mých dat ze zálohy na externím disku zpět do počítače. Asi po půl hodině a necelé stovce GB přenesených dat mi došlo, že já bych se vlastně mohl pokusit obnovit některé ze smazaných souborů, před tím, než si je přepíši obnovením zálohy.

A tak jsem uvažoval, co bych si asi tak mohl ještě zkusit zachránit. Ale považoval jsem to za předem prohrané, protože – obnovit jde jen soubory, nikoliv složky či celou adresářovou strukturu – a já, když už bych něco potřeboval zachránit, tak by o rozhodně nebyl jeden jedinný soubor, ale celá složka. I v tom jsem nakonec chyboval.

Po asi půl hodině kopírování jsem si ještě jednou vzpomněl na můj článek o exportu historie prohlížeče. Jedna kapitola se věnuje trošku postrannímu tématu – tomu, jak vlastně celý ten složitý postup exportu je možné s určitou nepřesností obejít jedním SQL dotazem nad jedním SQLite souborem.

Vyhlašujeme pátrání po souboru neznámého jména, střední velikost, přípona žádná

A tak jsem se pustil do hledání právě tohoto souboru. Teoreticky to triviálně: spusť program foremost a s jeho pomocí vyhledej všechny obnovitelné soubory a nech je obnovit. Z nich vyber jen soubory typu „SQLite databáze“. Z nich vyber ty, které obsahují databázi požadovaného schématu (věděl jsem, že musí obsahovat tabulku „favicons“). Pomocí mého nástroje vyexportuj (alespoň část) historii z tohoto souboru. A je hotovo!

První zádrhel nastal hned v prvním kroku. Program foremost nezná soubory typu „SQLite databáze“. Ty bylo potřeba ručně dodeklarovat (naštěstí nic složitého, stačilo jen specifikovat čím soubor začíná, tj. magic number, což je veřejně známá věc).

Druhým problémem bylo, že foremost obnovuje buďto všechny soubory všech známých typů, nebo jen určité zvolené typy (JPG, docx, ZIP, …). Bohužel, možnost obnovení zvolených typů se nevztahuje na ručně deklarované typy, takže jsem musel bohužel obnovit úplně všechny soubory. S ohledem na to, že na externím disku, který byl pochopitelně jediným možným cílovým zařízením, už tak ležela záloha více než poloviny mého počítače, a k tomu ještě nějaké smetí k tomu (které fakt nebyl čas uklízet), docela jsem se toho obával. Z logiky věci – zachraňovat data z 400GB disku na disk, kde je volných necelých 100GB, matematicky nevychází i kdyby se podařilo souborů zachránit jenom čtvrtinu.

K mému překvapení to ovšem po pár hodinách nezhavarovalo na tom, že by se disk zaplnil zombie fotkami a tunami dávno smazaných PDFek z dob studí, nýbrž na skutečnosti, že se naplnil maximální počet souborů ve složce. Nevadí, tak u toho zkrátka budu muset sedět, sledovat to, a čas od času pomazat všechny obnovené fotky a videa, dokumenty, ZIPy, a zkrátka všechno, co nejsou databáze SQLite.

Externí disk může mít v každé složce maximálně šedesát pět tisíc pět set třicet šest souborů. Neptejte se mě jak to vím, prostě to vím.

Druhý problém, jak se ukázalo, se jala být skutečnost, že na disku je celá řada souborů, které začínají stejně jako databáze SQLite, nýbrž SQLite databází nejsou. V jednu chvíli to dokonce vypadalo, že nějaká aplikace (osobně se domnívám, že právě prohlížeč) má na každý databázový soubor jeden soubor textový, obsahující informaci o tom, v jakém formátu ta databáze je (to celkem dává smysl, než aby aplikace zkoumala co to je za typ databáze, podívá se do odpovídajícího pomocného souboru a ví to ihned).

Takže když jsem se zaradoval, že se mi podařilo zachránit již pár stovek SQLite databází během prvních pár minut, ukázalo se, že jen možná 1% jsou skutečné databázové soubory. Doplnil jsem si tedy jednoduchý filtřík, který odmazával soubory, které nejsou SQLite databáze, i když se tak pro foremost tvářily.

Z nižsích desítek opravdových SQLite databází jsem poté už jen průběžně filtroval ty, které (ne)obsahují kýženou tabulku/tabulky a dostal jsem se k jednotkám souborů. Současně jsem ale dále procházel disk a hledal další, pro případ, že by nějaký takový soubor byl umístěný někde vzadu.

Říká se, že když poskytnete skupince opic ideální podmínky k životu a do výběhu jim dáte neomezený zdroj papírů a tužek, za pár miliard let čistou náhodou sepíší celé dílo Shakespeara. Tak nějak jsem se cítil, když se mi při čtení dat z disku najednou změnil titulek okna na nějaké smetí. V těch miliardách bytů dat se totiž vyskytla escape sekvence na změnu titulku okna. Ano, někde na mém disku se nachází série znaků „\033]0;“ a „\007“.

Toto celé trvalo několik málo dní, při kterém procedura v různých stádiích spadla právě z důvodu přeplění výstupního adresáře. Takže jsem se nakonec s prohledáváním ani nedostal na úplný konec disku. Nicméně, dle prvotního průzkumu to vypadalo, že soubor, který hledám, už jsem dávno našel. Jak by si člověk domyslel – prohlížeč je jedna z prvních věcí, kterou člověk v počítači spouští, takže dává smysl, že jeho soubory budou „někde na začátku disku“, než se stihne zaplnit ostatními daty.

Na pitevně

Pátrání po zemřelém souboru jsem tedy ukončil a jal se prověřit kandidáty. Bohužel, žádný z nalezených souborů nebyl bez poškození. U jednoho namátkou vybraného jsem si vylistoval jeho obsah, a po pár megabytech dat jsem narazil na poměrně jasný a srozumitelný text nějakého konfiguračního souboru pro grafické prostředí (ale těžko říct, dost možná někde mezi těmi nečitelnými daty byl i nějaký PDF dokument z mé snahy o obnovení zálohy).

Nečitelná data SQLite souboru najednou obsahují něco, co vypadá podezřele jako konfigurační soubor
Nečitelná data SQLite souboru najednou obsahují něco, co vypadá podezřele jako konfigurační soubor

Poměrně nešťasten a vědoma toho, že je zle, jsem z povinnosti vyzkoušel pár „osvědčených“ triků, jak zachránit rozbitou SQLite databázi. Pochopitelně, žádný z nich není stavěný na to, že vám někdo přepíše kus souboru něčím úplně jiným, takže naprosto bez úspěchu.

Zkusil jsem také sáhnout po řešení ze světa Microsoft Windows. Našel jsem totiž nějaký „zaručeně 100% funkční SQLite prográmek na opravu poškozené databáze“. No, skutečnosti, že odkaz na stažení vedl na stažení úplně jiného prográmku (a ten „reálný“ odkaz byl kdesi dole v rožku malým písmem) a že po stažení a spuštění toho pravého, aplikace vypadala úplně jinak, než v návodu, přeskočím, protože na to už jsem ve světě Microsoftích technologií tak nějak zvyklý.

A jak to dopadlo? Jednoduše: Ten skvělý, profesionální a 100% funkční prográmek nedokázal z databáze vytáhnout ani seznam tabulek v ní obsažený. Tedy něco, co bez problému zvládl i výchozí klient SQLite. Na neúspěch jsem byl připravený, ale tato pointa mě vyloženě pobavila.

Na pohřbu je každý generál

A tak tu teď sedím, koukám na 8 zachráněných SQLite databází, z nichž některé patrně obsahují nějaké informace o mnou naposledy navštívených stránkách, ale notně poškozené, takže bez přímé cesty, jak z nich tyto informace dostat. Ustoupil jsem z toho, že bych rád měl kompletní zálohu celé historie prohlížeče. Stalo se pro mě přijatelné získat jen seznam naposledy navštívených stránek a data jejich posledních návštěv. Nakonec to vypadá, že – budu-li mít štěstí – podaří se mi získat alespoň pár webových adres několika navštívených webů v poslední době.

Rád bych se podíval na standart SQLite a na formát jeho databázového souboru. V ideálním případě se mi podaří přesně identifikovat přepsanou část a, řekněme, vyprázdnit ji. Sice přijdu o některá data (v ideálním případě by se však netýkala samotného sezanamu webů, ale např. cookies), ale mohlo by se mi podařit databázi zprovoznit a umožnit tak její export.

Jak je vidět, i prostý výpis poškozeného databázového souboru stále obsahuje nějaká "reálná" data (webové adresy).
Jak je vidět, i prostý výpis poškozeného databázového souboru stále obsahuje nějaká „reálná“ data (webové adresy).

Ale domnívám se, že nejspíš stejně zkončím u toho, že celý soubor prostě prohledám na výskyty všeho, co začíná znaky „http“ a to si prostě někam uložím. Operační systém unix (a to zdědil i jeho pravnuk Linux) vznikl za účelem vyhledávání textů, takže by to myslím byla celkem vkusná tečka za celým tímto příběhem.

Závěrem

Co říci závěrem? Zálohujte! A ještě bych dodal: Zálohujte! A na závěr: Zálohujte!

Tento příběh naštěstí nedopadl tak špatně. Vlastně by se dalo říci, že dopadl dobře (ale to nemohu, protože ještě zálohu nemám v novém počítači). Co jsem se tímto snažil vypíchnout je skutečnost, že i když má člověk to nejdůležitější (myšleno třeba 99%) zazálohováno, a octne se v ohrožení, že záloha ani toho jednoho procenta už nebude možná, nesmí za žádnou cenu panikařit.

Jak se ukázalo, počítač (či disk) nebyl v tak špatném stavu, aby nemohl ještě pár dní fungovat vesměs normálně dále. Měl jsem tedy (s velkou pravděpodobností) dostatek prostoru na to, si v klidu dozálohovat zbylé 1% dat. Ale šok z toho, že „počítač kleknul“ a obavy z rizika, že selže i záloha zbylých 99%, zabránily jinak běžnému odstupu, nadhledu a racionálnímu vyhodnocení situace. Je to přirozené – člověk se dostane pod palbu emocí a v takové situaci si prostě nedokáže říct: „Hm, je to blbý, ale teďka už to raděj vypnu a do zítřka promyslím, co s tím. Teďka bych určitě jen napáchal víc škody než užitku.“

A přesně na toto se snažím upozornit. Osobně doufám, že se nikdo do podobné situace nikdy nedostane, ale když už ano tak: zachovejte klid. A pokud jde opravdu o život, svěřte počítač do rukou odborníků, čím dřív, tím líp. Těch pár stovek za to přece stojí, ne? Vždyť jde přece o život.

A víte, co je na tom všem nejlepší? Že si toto někdo někdy bude číst zcela určitě poté, co do vyhledávače vložil frázi typu: „pomoc klekl mi počítač jak z něj zachránit data“ a jediné, co mu v této situaci tento článek dá bude to, že mu řekne: „jo, je to tak, jsi trouba, měl sis všechno pořádně zálohovat“.

RIP Lenovo „Lenny“ Thinkpad E520, 2012 – 2022

Export historie prohlížeče: proč to dělat jednoduše, když to jde složitě?

Stala se mi – slovy klasika – takový ošklivý a skoro bych řekl zlý, nepěkná věc. Zavřel jsem si okno prohlížeče se spoustou záložek (karet, panelů) a omylem si toto zavřené okno nahradil nově otevřeným prázdným. Po jeho zavření se tak „naposledy zavřeným“ oknem stalo toto nové, prázdné a to původní bylo nenávratně ztraceno. Leda, že bych vynalezl stroj času a vrátil se do chvíle, kdy jsem tyto mé stránky měl naposledy otevřené...

A tak jsem začal bádat, jak z prohlížeče Opera vydolovat historii v nějakém rozumném, tedy strojově čitelném formátu. První myšlenka byla prohledat domovský adresář a hledat vše, co by mohlo mít co dočinění s Operou (tedy ~/.config/opera a ~/.cache/opera ), jestli tam třeba nenajdu soubor history.xml. Bohužel nic takového a googlení mě akorát přivedlo k myšlence, že něco takového dost dobře není možné. (Fail #1: V závěru se ukázalo, že to tak úplně není pravda, ale k tomu se dostaneme.)

Prohlížeč Opera je vlastně Chromium. Teoreticky by tak mnohé z toho, zde uvedeného, mohlo fungovat i v Chromiu a tudíž i v Google Chrome a snad dokonce možná i v Microsoft Edge.

Pár sekund jsem také uvažoval o tom, že by to mohl umět nějaký plugin. Prohlížečové pluginy obecně ale nemám zrovna v lásce, kromě blokování reklamy (což ovšem Opera dělá nativně), mám pocit, že jen prohlížeč zbytečně zpomalují. Navíc je to další potencionálně škodlivý (resp. děravý či napadnutelný) kód, ještě navíc přímo v prohlížeči.

Trocha Javascriptu ještě nikdy nikoho nezabila …

Navíc, možná proto jsem inspirován youtubery jako colinfurze nebo Michael Reeves (#karanténa) začal uvažovat o nějakém šíleném a bláznivém řešení. Navíc, jsem (si) chtěl ukázat, že se Tom Scott mýlí a hackovat jde stejně dobře i na Linuxu. A v momentě, kdy jsem zjistil, že historie v Opeře je jen další „HTML stránka“, bylo rozhodnuto: Trocha Javascriptu ještě nikdy nikoho nezabila! (Upřímně se obávám, že asi ano, tím si ale nekažme tuhle chytlavou frázi.)

historie v Opeře
Historie v Opeře je jen speciální stránka

Verze 1.0: vize

Moje myšlenka byla tedy jednoduchá – budu-li si chtít zazálohovat historii prohlížeče, otevřu „stránku“ historie (dostoupnou mj. pod url about://history), otevřu vývojářskou konzoli (tu vám na této stránce Opera oficiálně neumožní rozbalit, ale Ctrl+Shift+I funguje), vložím tam nějaký kus kódu, odentruju – a pár vteřin či desítek vteřin počkám. (Fail #2: Je zajímavé, že mě celou dobu nenapadlo prostě pomocí Ctrl+S celou stránku uložit a pak si ji někde v klidu zpracovat.)

Samotný kód pak měl za úkol projít celou stránku, sesbírat záznamy historie a „uložit je“. Nastala tedy otázka, jak/kam data „uložit“. Prohlížečový Javascript nemá moc možností jak ukládat data – ten nejzákladnější, tj. localStorage, se v Opeře sype do nějakých „data“ souborů kdesi v konfiguraci. Navíc bych si troufl říct, že by na této stránce ani nefungoval.

Prohlížečový javascript
Původní myšlenka byla o tom, že uživatel do prohlížeče nakopíruje nějaký kód a zmáčkne Enter

A tak jsem si řekl, že když už bude nějaký Javascriptový kód běžet v prohlížeči, proč rovnou nevytvořit jednoduchou node.js webovou službu, které bude prohlížečový skript data posílat? Taková služba pak může data sypat třeba do sqlite databáze. #Too_much_javascript_to_handle

Tak třeba by nikoho nezabilo ani trochu víc Javascriptu …

Já o pár vteřin později

Teoreticky. Pustil jsem se tedy do toho. Hned první drobný zádrhel byl, že Opera záznamy v historii zobrazuje (resp. načítá a zobrazuje nové a nové) postupně jak člověk scrolluje dolů stránkou (ne moc překvapivě). Nestačilo tak pouze otevřít stránku a vyextrahovat záznamy – bylo nutné odscrollovat postupně až dolů a nechat postupně načíst všechny záznamy.

Verze 1.1: první krůčky

Řekl jsem si, že než listovat celou stránkou úplně dolů a pak odesílat na node.js službu tisíce záznamů, mohl bych sledovat změny ve stránce a „reportovat“ průběžně všechny přidané záznamy. Pochopitelně s automatickým scrollováním, jakmile by byly všechny nově přidané záznamy bezpečně zpracovány.

Dalo se totiž očekávat, že Opera nebude úplně nadšená z toho, že někdo listuje historií až na úplné dno. Dle mých odhadů se mohlo jednat klidně o 10 tisíc záznamů (Fail #3: aktuální odhad mám cca 100 stránek za den, za rok a kousek tedy téměř 50 tisíc) a s ohledem na to, jak titěrně vypadal posuvník (scrollbar) už po prvních pár scrollech dolů, kdy jsem projel historii za poslední dva dny, dalo se tušit, že to bude záhul. (Fail #4: Při hlubším zkoumání vyprodukované databáze, jsem zjistil, že scrollování se vždy zastavilo asi na 95. dnu a další historie už se nenačítala. Podařilo se mi dohledat, že Opera si totiž pamatuje historii jen asi tři měsíce zpětně. Ve výsledku tak stránka byla asi 10x menší, než jsem očekával.)

Vytvořil jsem tedy skriptík, který monitoroval změny v dokumentu a reportoval nově přidané záznamy. S ohledem na to, že záznamy se přidávají po určitém počtu (konkrétně po stovce) a nikoliv po celých dnech, bylo potřeba sledovat i to (záznamy jednotlivých dnů Opera zobrazuje na oddělených panelech, takže přibývají jak dny v panelu posledního dne, tak i nové panely se svými záznamy).

Přidal jsem i automatické scrollování po skončení zpracování (a pro jistotou i nějaké čekání, přecijen natažení a zobrazení stovky záznamů vteřinku, dvě, pět zabere). Vše fungovalo naprosto skvěle, jen s jedním drobným zádrhelem – po asi třech odscrollováních došlo k zřejmě internal erroru v Opeře (prostě spadl kód, který měl renderovat HTML na základě dat z backendu) a stránka přestala na scrollování reagovat. Vlastně se tak trochu celá rozbila a přestala reagovat tak nějak všeobecně.

Verze 1.2: jeden krok vpřed, dva vzad

To mi docela zhatilo plány a vzhledem k tomu, že nepomohlo ani navýšení čekání (pro případ, že by šlo o souběh) či trochu efektivnější/efektnější způsob zpracování přidaných záznamů, musel jsem se s tímto poměrně elegantním řešením rozloučit.

Došlo to tak daleko, že jsem se chvíli dokonce hrabal zdrojovými kódy Opery, snažil jej zprvu debuggovat a po neúspěchu studovat, jak vyvolat načítání nových záznamů ručně, tj. bez scrollování. To se mi nepodařilo, zato jsem našel přímo modul implementující dotazování nad historií. Tedy něco, co by mi vracelo záznamy přímo jako Javascriptové objekty, bez nutnosti parsování HTML, resp. proházení stromu dokumentu!

Funguje to perfektně, až na to, že vlastně vůbec…

Bohužel, ani to se mi, zcela nepřekvapivě, nepodařilo rozchodit (povětšinou jsem byl poslán do oněch partií různými vrstvami bezpečnostní politiky) (dává to smysl, kdyby si jen tak nějaký Javascript mohl takhle hrát s interními věcmi prohlížeče, asi by prohlížeč brzo doprohlížečoval) . Koneckonců, v jednu chvíli jsem si říkal, že dost možná i proto mi můj skriptík padal – Opera zkrátka možná blokovala automatizované zpracování stránky. (Když nad tím tak přemýšlím, tak to je asi hloupost, padalo to na něčem ohledně stylů, což moc nevypadá jako úmysl.)

Dospělo to až tak daleko, že jsem chvíli koukal na stránku dokumentace k Browser History API pro vývojáře pluginů. Ani pořádně nevím, jak jsem se tam vlastně dostal, ale s ohledem na to, že jsem si plugin nechtěl instalovat jako uživatel, natož si jej přímo vyvíjet, stránku i celou myšlenku jsem rychle opustil a lehce ustoupil z mých požadavků.

Verze 1.3: Tak už to zmáčkni!

Rezignovaně jsem opustil představu, že celý problém vyřeší jedna nodej.js služba a jeden kód prostě vložený do konzole prohlížeče, a vytáhl bazuku. Sáhl jsem totiž po prográmku xdotool, který emuluje, resp. „fejkuje“ primitivní akce uživatele, tj. pohyb nebo klikání myší a stisky kláves.

Scrollování jsem tedy vyřešil jednoduchým Bashovým skriptíkem, který do svého ukončení prostě pořád dokolečka mačká Page Down (pochopitelně, opět, s nějakým čekáním). Spolu s tím jsem také z mého prohlížečového kódu vyhodil celý ten problematický monitoring stránky a prostě jej nechal staticky a jednorázově projít celou stránku a naposílat všechny nalezené záznamy.

Tohle celé jsem zabalil do jednoduchého skriptu, který:

  1. Požádá uživatele, aby otevřel v prohlížeči historii (to by samozřejmě šlo udělat jedním příkazem, ale myslím, že to celému skriptu přidává na „dramatičnosti“)
  2. Řekne mu, aby si otevřel vývojářské nástroje (opět, i to by šlo udělat pomocí xdotools, ale chtěl jsem ponechat co nejvíc kontroly uživateli)
  3. Spustí skript na scrollování dolů
  4. Jakmile stránka dojede dolů (nebo kdykoliv si uživatel usmyslí), má jej ukončit
  5. Nahodí se node.js služba, založí se databázový soubor, vytvoří tabulka
  6. Uživateli je předložen částečně minimizovaný (tj. bez nadbytečných bílých znaků) Javascriptový kód, který má spustit v prohlížeči
  7. Po doběhnutí uživatel dá pokyn k odpojení od databáze a zrušení služby
  8. Na závěr je jen pro kontrolu vypsán počet záznamů v databází a skript končí.

Nezbývalo, než to celé spustit. Všechno klapalo, dokonce i reportování node.js službě. Akorát to spadlo po pár sekundách, protože prohlížeč nedokázal udržet tolik otevřených spojení současně – XHR požadavky se totiž v základu posílají asynchronně, tedy se nečeká na dokončení předešlého a tudíž je prohlížeč chtěl poslat prakticky všechny v jeden okamžik. Opraveno a nyní už celý skript proběhl a nasbíral skutečná data. Jenže …

insufficient resources, moc současných spojení
UUUPS! Opera evidentně nezvládne víc, než pár tisíc současných spojení …

Verze 1.4: Zrychlujeme

… jenže stále tam bylo několik „ale“. Tak zaprvé, kód, který měl uživatel zkopírovat do prohlížeče, jen slepě odstraňoval nadbytečné bílé znaky. Což, jak jsem záhy zjistil, mělo nedozírné důsledky v případě, že v kódu byl někde jednořádkový komentář. V takovém případě tedy zakomentoval zbytek celého kódu. Oukej, nějakým způsobem jsem tam doplnil odstraňování jednořádkových (a když už, tak už i víceřádkových (bo minimizace!)) komentářů.

Další problém, který mě trápil, byla rychlost nahrávání. Nebylo nijak zvlášť překvapivé, že vzít jeden JSON záznam, poslat ho přes XHR na node.js server a tam ho jedním dotazem vložit do databáze bude při tisících takovýchto záznamů docela neefektivní. Přidal jsem tedy dávkové zpracování.

K mému poměrně velkému překvapení se nahrání tisíce záznamů propadlo z dvou a půl minut na 14 sekund (při posílání po 10), resp. na 6 sekund (při posílání po 20) nebo necelé tři sekundy (při posílání po 50). Musel jsem kvůli tomu ale navýšit maximální velikost požadavku na 10MB (občas bylo zřejmě některé URL příliš dlouhé) (Fail #5: zřejmě to nebylo URL, ale favicona ve formátu data:uri). Nakonec jsem tedy nechal velikost dávky na 20 (při 50 by se zvyšovala šance že node.js odmítne celý balík 50 záznamů, o které bych tak přišel).

Pak už jen drobnosti jako odpojit se korektně od databáze při ukončování, a doplnit trošku informativních výpisů (jak do konzole v prohlížeči, tak při běhu hlavního skriptu).

Mimochodem, shruba v této době (když jsem při jednom testování nechápavě zíral, proč se scrollování zastavilo na datu někdy v únoru – a dál ani krok) zjistil, že Opera si pamatuje historii jen tři měsíce zpětně. Na jednu stranu docela šok a zklamání, na druhou stranu motivace mít skript připravený k opětovnému použítí. Ale o tom pozděj, teď jedna odbočka.

Odbočka 1.1: Primitivní ale funkční

Dobře, ale – říkáte si, co se sesbíraným seznamem navštívených stránek? Samozřejmě, až budu mít sesbíraných víc záznamů, než poslední tři měsíce, půjdou dělat docela zajímavé statistiky. Od nenajvštěvovanějších serverů přes opakovaně navštěvované přímo konkrétní stránky, až po histogram návštěv různých webů dle denní doby/dne v týdnu. #Science

A nebo si vytvořit obrázek se faviconkami všech navštívených stránek. Tedy tak trochu něco jako reddit place nebo The Million dollar homepage – jen sestavené mnou samotným.

První verze faviconek
Prvotní verze stránky faviconek, ještě bez jednotné velikosti.

Koneckonců, z tohoto důvodu již úplně první verze exportéru historie pracovala s cestou k faviconám stránek zobrazených v historii. Myšlenka tedy byla jednoduchá – skript vezme vyexporotovanou databázi navštívených stránek a vygeneruje jednoduchou HTML stránku s obrázkem (faviconkou serveru) pro každý záznam z historie.

Teprve v tento moment jsem se hlouběji podíval na favicony získané z historie. Zjistil jsem, že to vlastně vůbec nejsou adresy reálných ikonek, nýbrž jen odkazy do interní cache favicon Opery. Tedy nepoužitelné. Použil jsem tedy starý trik, nechal jsem si vylistovat jen názvy serverů a ve stránce vyjmenoval všechny obrázky s URL https://SERVER/favicon.ico. Samozřejmě ne všechny takové existují (typicky třeba mnou docela často navštěvované mapy.cz) a tak se u nich pomocí alternativního textu zobrazil křížek. (Asi by šlo na jednotlivé servery poslat požadavky, ty zparsovat a získat přímo konkrétní adresy faviconek, předmětem tohoto skriptíku ale bylo jen rychlé a plus mínus funkční řešení.)

Na odzkoušení hypotézy celkem cool, ukázalo se, že to může fungovat. Ale jak pravil klasik – not great not terrible.

Odbočka 1.2: Hloupé, ale ještě funkčnější

Napadlo mě ale, že favicony by si prohlížeč zcela určitě měl cachovat. A taky, že (bavíme-li se stále o Opeře) – ano! V sqlite databázovém souboru ~/.config/opera/Favicons se nachází parta tabulek obsahující informace o faviconách. Pak už stačilo jen nastudovat si jejich strukturu a napsat stručný dotaz, který vylistuje URL favicon pro všechny servery. K mému překvapení, prohlížeč si pamatoval všechny favicony pro všechny servery v nedávné historii. (#Fail 6: Historii? Ano, cache favicon je vlastně také historie. Pamatuje si seznam navšítených adres (pro každou z nich i faviconku) a datum a čas posledního přístupu. Nevýhodou ale je, že si u každé stránky pamatuje vždy jen poslední přístup. Teoreticky by to ale jako jednoduchá strojově čitelná historie mohlo postačovat.)

Tentokrát už by mi obyčejný Bashový skript nestačil, takže jsem sáhl po Pythonu. Prostě si pro každý záznam v historii pomocí jeho serveru najde odpovídající URL favicony a tu vypíše jako obrázek. Protože ale mám k dispozici informací víc, každá faviconka je klikatelná (vede přímo na patřičnou stránku) a s popiskem (tooltipem) (titulek stránky). (Fail #7: Vzhledem k tomu, že historie a cache favicon se nacházejí v různých databázích, mám jejich „spojení“ řešené až na straně v Pythonu. Sqllite samozřejmě umí i to, pak by se skript zkrátil a většinu práce by odvedl jeden SQL dotaz. Skript by pak šel napsat i přímo v Bashi bez nutnosti Pythonu.)

faviconky!
Faviconky! (výřez!)

Tento skriptík je tedy trochu víc promakanější, ale hlavně – zobrazí favicony všechny (pochopitelně, pokud v mezičase některá nebyla přesunuta), a to včetně tooltipů a vlastně i konkrétních URL (po přejetí nad odkazem se jeho adresa zobrazuje někde dole). Jedinou nevýhodou je, že při generování musí být zavřená Opera. Databáze je pochopitelně Operou hojně využívána a je tak tímto procesem blokovaná. To trošku kazí dojem z vygenerované webové stránky, ale myslím, že přínosy jasně vedou.

Verze 1.5: budoucnost

Dobře, ale zpět k exportéru historie. Jak jsem zmiňoval, nyní už je dokončen a plně funkční, aktuálně se již jen dolaďují některé detaily, které usnadní dlouhodobější používání.

Jeden z nich by určitě mělo být nevkládání duplicitních záznamů (když budu zálohovat každý měsíc, předposlední a předpředposlední měsíc budu vždycky dvakrát). S tím souvisí, že skript by neměl vyžadovat neexistenci databázového souboru při spuštění a – nejlépe cestu k němu nemít zadrátovanou napevno, ale na vyžádání od uživatele.

Také s ohledem na zkušenosti získané tvorbou generátoru stránky s faviconkami, odebrat z exportu favicony. Je to hodnota nicneříkající a tudíž zbytečná. Obdobně, datum a čas návštěvy stránky by asi taky bylo rozumné ukládat jako datum a čas a ne jako text natvrdo vystřižený ze stránky.

Zapracovat by se dalo i na generátoru stránky s faviconkami. Například ikonky rozházet, a zobrazovat jejich velikost podle návštěvnosti daného serveru (tj. něco jako tag cloud). Nebo je prostě a jednoduše jen náhodně zamíchat.

Závěr

Závěrem bych tradičně jen uvedl odkaz na GitHub projektu (pokud odkaz nefunguje, pak ještě nebyla dokončena verze 1.5). Nepředpokládám, že by se našel někdo, kdo si jej stáhne či na něm nedejbože bude dělat úpravy.

Vlastně celý tento článek vznikl jen jako výpis strastí, se kterými se člověk může při takovém tom domácím hackování setkat. Dá se očekávát, že s prvním redesignem Opery se minimálně ta prohlížečová část celá rozsype, ale třeba do té doby nasbírám alespoň nějaké informace o mé aktivitě na internetu. A nebo třeba ne. Možná mě přestane bavit pokaždé nechat dlouhé minuty (kolik je to celkem se mi ještě nepodařilo přesně určit, celkový export jsem spouštěl vždycky přes noc) čekat, než se odscrolluje stránka s historií.

A nebo se mi podaří dopátrat alespoň některé ze ztracených záložek (stránek, panelů, karet), kvůli kterým tohle celé vzniklo. Ale musím se přiznat, že na to jsem v průběhu vývoje tohoto udělátka úplně zapomněl.

Disketo: úklid fotek

Tento článek navazuje na předcházející článek, ve kterém jsem představil prográmek disketo. Ten slouží k vyhledávání souborů a složek na základě rozličných kritérií, jako je název složek či souborů v nich obsažených, počet souborů určitého typu, nebo počet shodných souborů ve dvou (a více) různých složkách.

V tomto článku se podíváme na trochu reálnější použití disketa – a to úklid ve fotkách. Fotek totiž často bývá hodně, bývají z různých zařízení – a často od různých lidí. Některé jsou poctivě roztříděné, některé méně, některé jen tak narychlo zkopírované. Občas je na čase sednout a projít si všechny místa, kde se fotky nacházejí (počítače, flashky, externí disky, paměťovky, cloudy, …) – a udělat v nich pořádek. Sesypat do jedné složky, smazat ty které už mezitím byly roztříděny a naopak případně roztřídit ty, které roztříděné nejsou.

Disketo může být v mnohém z toho poměrně nápomocné. Umožní vám najít celkem očividně zapomenuté či neroztříděné fotky – a to dokonce bez toho, aniž byste vůbec museli vidět jedninou fotku. Chcete to zkusit? Pojďme se do toho pustit.

Ještě než se do toho radostně pustíte, jen bych připomněl, že disketo asi není prográmek pro běžného uživatele. Pro jeho používání je vyžadována pokročilá znalost práce s počítačem na úrovni ovládání příkazové řádky a základů programování či skriptování.

Složky s fotkami (první způsob)

Základem každého třídění je sesbírat si všechny možné složky ze všech možných míst. Vezmeme disketo a vylistujeme se všechny složky, jež se jmenují např. foto či fotky. Jak už víme, disketo pracuje s regulérními výrazy, takže je možné názvy zkombinovat. Je tak možno použít např. vzor fot(o|ky). Pozor však na malá a velká písmena, ty disketo rozlišuje.

Předchozí vzory nám vylistují všechny složky, odpovídající (jejiž celá cesta odpovídá) zadanému vzoru. Tedy všechny složky foto a fotky a to včetně podsložek. Můžete se tak přesvědčit, jak strašně velké množství složek s fotkami doma máte. Nás ale na úvod bude zajímat jen ty samotné složky foto či fotky, bez jejich podsložek. Toho se naštěstí dá v disketu dosáhnout docela snadno, stačí říct, že cesta musí textem foto nebo fotky končit, tedy fot((o)|(ky))/?$ (volitelné lomítko na konci je jen pro jistotu).

Pak už stačí složky jen vypsat. Disketo skript slozky-s-fotkami-1.ds tedy bude vypadat následovně:

Skript spustíme se seznamem všech našich uložišť (v mém případě složky obrazky a zaloha přímo v počítači):

Složky s fotkami (druhý způsob)

Pokud však máte ve fotkách totální chaos a nemůžete ani říct, jak se vlastně jmenují všechny složky s fotkami, je tu druhá možnost. Můžete zkusit vyhledat složky obsahující fotky, tedy JPG soubory. Takových bude ovšem hromada (JPG soubory jsou jeden ze základních formátů obrázku, takže i bez fotek jich v počítači budete mít tisíce).

Prostý vzor (.*)\.jpg by tak našel zbytečně moc souborů. Lepší by bylo použít vzor například PICT_[0-9]{7}\.JPG, pokud váš foťák produkuje soubory ve formátu PICT_1234567.JPG. Samozřejmě, i zde se vzory dají kombinovat, takže můžete vytvořit vzor třeba (PCIT_[0-9]{7}\.JPG)|(Photo[0-9]+.jpg)|(fotka \([0-9]+\).jpg). Stejně jak v minulém případě je rozumné ukončit vzor znakem $ (lomítko už nyní opravdu nehrozí; pokud tedy nemáte na disku složku s názvem odpovídající vzoru).

Použijeme skript slozky-s-fotkami-2.ds, který prvně vyfiltruje podle názvu adresáře (podobně jako v předešlém případě, ale mírněj). To se může hodit např. pro vyloučení složky Windows, resp. omezení vyhledávání jen na uživatelské adresáře, ale není nic špatného nastavit tento parametr na (.*) (nebo rovnou celý řádek vypustit).

Dále provede filtraci podle souborů. A to tak, že sítem projdou všechny složky, které obsahují soubory dle vzoru výše, a to, pokud jich obsahuje alespoň uvedený počet. My tuto volbu ponecháme na uživateli. Čím nižší číslo, tím více falešně pozitivních složek disketo najde (např. grafika k programům), naopak čím vyšší, tím víc skutečných složek s fotkami bude ignorováno. Bude to chtít trochu experimentování, proto jej necháme uživateli zadat až při spuštění. Tedy:

A spustíme (budeme hledat složku s alespoň dvěma fotkami):

Zajímavostí je, že nyní jsme našli i fotky školního projektu, které nám předchozí skript nenalezl.

Jen tak mimochodem, při velmi vysokém čísle (stovky či třeba tisíc) pak můžete obdržet složky, které obsahují enormní množství fotek. Získáte tak přehled – jednak o tom na jaké akci (či v jakém časovém úseku) jste opravdu hodně fotili – ale zřejmě také o tom, která složka pravděpodobně obsahuje nevytříděné a nepromazané fotky.

Hledání duplicit – složky

Výborně, máme tedy seznam všech složek obsahující fotky. Ze by bylo fajn si jej ručně projít a zkontrolovat. Přecijen, v počítači můžete mít různé složky a vzoru tak může odpovídat i například složka Xbfotoxb20am, která ale zřejmě nebude obsahovat fotky.

Také se ukázalo rozumným shromáždit si všechny složky s fotkami na jedno místo. Založte si složku třeba UKLID_FOTKY a všechny si tam nakopírujte/přesuňte. Zjednoduší to práci i vám i disketu, který nebude muset pořád dokola prohledávat všechna uložiště (bohužel, disketo je v tomhle poněkud hloupý a tak prohledává pokaždé vše, bez ohledu na to, jestli se něco změnilo či ne).

Máte? Výborně. (Já tento krok v rámci jednoduchosti vynechávám.) Nyní se jen tak pro kontrolu podíváme, jestli některou ze složek s fotkami nemáte dvakrát (či dokonce vícekrát). Přecijen – často člověk zálohuje až moc – a některé zcela totožné fotky může mít na více místech – i když jsou to pokaždé tytéž. Necháme disketo, ať vám vyhledá duplicitní složky (v první fázi pouze takové, které mají shodný název). Použijeme následující skript:

Disketo vám vypíše všechny složky, které mají nějaké „dvojče“ (tj. jinou složku se stejným názvem). Jak si vypsat, která (či které, pokud je jich víc) to je, si povíme za chvíli.

V mém případě však žádné duplicitní složky nenalezl, takže jdeme pátrat dál.

Hledání duplicit – soubory

Když dva dělají totéž není to totéž – a stejně tak, když se dvě složky jmenují stejně, neznamená to, že jsou si věrnou kopií. Složky s názvem „dovolená u moře“ „vánoce u Nováků“ či „šedesátiny“ by mohly vyprávět.

Pomocí disketa můžeme i tyto hříšníky odhalit. Použijeme skript pro vyhledání složek s duplicitními soubory. Skript porovná všechny složky (včetně jejich obsahů) mezi sebou navzájem a pokud najde shodu (složka obsahuje víc než zadaný počet shodných souborů), složku vypíše.

A podle čeho je bude porovnávat? Nejjednodušší je porovnávání podle názvů souborů. Takový disketo skript bude vypadat následovně:

Pro případ, že by název souboru nebyl dostatečný (např. pokud foťák čísluje vždy od nuly a stejné názvy souborů by se tak často opakovaly) je možné porovnávat nejen podle názvu souborů, ale také podle velikosti. Minimálně u fotek je poměrně nepravděpodobné, že by dvě fotky měly stejný název i stejnou velikost. V takovém případě se namísto filter_directories_with_common_file_names použije filter_directories_with_common_file_names_with_size.

Teoreticky by také bylo možné porovnávat podle data poslední změny či vytvoření souboru. To však u souborů, které vznikly zkopírováním moc nedává smysl (soubor kopie vzniká až při kopírování, nemá tedy stejný čas vzniku jako původní soubor), takže v disketu není implementován a musel by se naprogramovat ručně (což ovšem není nemožné, disketo s tím tak trochu počítá).

Každopádně, my se budeme držet původního porovnávání dle jména souboru. Skript nám vypsal, které složky mají nějaké „dvojče“, ale nevíme jaké:

Abychom to zjistili, budeme změnit způsob, kterým se vypisují nalezené složky, tj. poslední příkaz našeho skriptu. Bohužel, teď už se neobejdeme bez aktivního programování, je potřeba naprogramovat vlastní „vypisovač“, tedy subrutinu, která vypíše, co přesně potřebujeme. V našem případě chceme vypsat u každého nalezené složky také ty, které jsou jejími dvojčaty (opět, může jich být víc). Bez dalšího vysvětlování:

Výsledek je mnohem informativnější (pro lepší přehlednost doporučuji zkrátit cesty, tj nahradit např. /home/martin/obrazky za O a /home/martin/zaloha za Z):

Vidíme tedy, které složky obsahují podezřele společné soubory. Je tu jistá šance, že se jedná o kopii téhož obsahu – v našem případě složka nafoceny-projekt poměrně pochopitelně obsahuje také soubory ze složky s fotkami, proto se nám vypsala. Často ale jen narazíme na složku, která jen obsahuje neprotříděné či nepromazané soubory oproti jiné – a přitom se nám vypíše jako duplicita.

Tomu asi úplně nejde zabránit, nicméně mohli bychom si vypsat, kolik souborů obsahuje první složka, kolik druhá – a kolik z nich mají společné. (Šlo by vypsat soubory všechny, ale to by bylo poněkud nepřehledné.) Něco takového najdeme v souboru scripts/find-common-directories.ds. Ten nám vypíše (první číslo je počet souborů složky na začátku řádku, druhé číslo počet společných souborů a třetí číslo počet souborů v druhé složce):

Pokud jsou všechna tři čísla stejná, pak jsou obsahy obou složek (zřejmě) totožné. Než ale jednu z nich smažete raději si je obě otevřete a obsahy zkontrolujte (jak jsem psal, porovnáváme pouze na základě názvů souborů).

Další poměrně pozitivní případ je typu 120/49/49 (a pochopitelně tedy i zrcadlový), tedy že všechny soubory z druhé složky se dají najít také v první složce. Soubory v druhé složce tak nejspíš oproti té první prošly promazáním či roztříděním. (A nebo se naopak část z nich ztratila při překopírování!)

Pokud budou čísla zcela rozdílná, pak se bude jednat o naprostý mišmaš a fotky bude bohužel potřeba projít ručně.

Hon na Otesánka

Máte-li odebrány všechny duplicitní fotky a stále máte pocit, že vám moc místa na disku neubylo? Můžete se zkusit poohlédnout po největších žroutech místa na disku. V případě fotek to budou pravděpodobně videa. Dost možná tam někde máte dvouminutový záběr vaší kamarádky, jak tančí v temném baru na stole. Ano, přesně ten typ videí, kde není absolutně nic vidět, zato je tam slyšet celá hospoda. Pominu-li fakt, že takováto videa by vůbec neměla vznikat, natož se dostat až do rodinného alba, tak mohou být taky poměrně pěkný Otesánek – jedno takové video vydá klidně z pár desítek fotek.

S odhalením podobných souborů může pomoct například unixový prográmek baobab, neboli Analyzátor využití disku, nicméně podobnou službu nám s trochou snahy poskytne také disketo. Začneme tím, že použijeme skriptík pro vypsání souborů fotek s jejich velikostí. Například skript:

Vypíše u každé fotky její velikost v (kilo)Bajtech:

A teď trocha hrátek s unixovým shellem. Následující příkaz spustí disketo s předchozím skriptem, u výpisu prohodí sloupce (aby byla velikost první), seřadí (tedy podle velikosti) a vypíše prvních 5 souborů:

Já ve složkách žádná videa nemám, ale je vidět, že fotky z loňska jsou víc, než dvakrát větší, než ostatní. Kdybych tedy potřeboval uvolnit místo, už bych věděl, na které fotky sáhnout jako první.

Kontrola zálohy

Posledním, co si ukážeme, je jednoduchá analýza záloh. To se může hodit třeba v případě, že někde najdete zapomenutou a dost možná nekompletní zálohu, a budete potřebovat zjistit, jestli náhodou neobsahuje nějaké cenné či ztracené soubory.

Vlastně je to docela jednoduché – pomocí disketa si vylistujeme všechny soubory jak na aktuálním, tak na záložním uložišti a oba seznamy souborů vypíšeme do souboru. Pak už jen soubory porovnáme, nejjednoduššeji pomocí comm (graficky pak např. pomocí meld). Pro vylistování souborů použijeme následující disketo skript:

a poté (sed je použit pro odstranění společné části cest):

vypíše soubory, které jsou ve složce se zálohou, avšak nikoliv ve složce obrazky.

Porovnání složek graficky pomocí aplikace meld

Závěrem

Jak je vidět, disketo dokáže být celkem užitečná hračka. Samozřejmě opravdový potenciál tohoto pidiprográmku ocení asi jen programátor na linuxu, který si rád hraje s příkazovou řádkou, ale třeba se jednou dokopu, dopíšu dokumentaci a přidám i dummy verzi pro běžného smrtelníka.

Udělejte si pořádek v PC s nástrojem disketo!

Víte, co udělá programátor, když si musí roztřídit fotky? Správně, napíše si na to program. A víte, co udělá informatik, když si musí roztřídit fotky? Navrhne si framework a spolu s ním i vlastní skriptovací jazyk. A napíše si na to program.

Co je to Disketo_Framework?

A teď vážně. Disketo_Framework, neboli zkráceně prostě disketo, je nástroj pro, řekněme pokročilé prohledávání diskových uložišť. Tedy všech pevných, nepevných, externích i interních disků, flash disků, pamětových karet a já-nevím-čeho-ještě. Zkrátka všeho, co obsahuje soubory a složky.

A proč? Nu, protože občas je nutné všechna tato uložiště projít a udělat si v nich pořádek. Ano, mluvím na vás, jež shraňují data roky, a pak jednou za čas, když jim začne docházet místo, tak vymýšlí co smažou. Ano, přesně na vás, jež jednou za dva roky zkopírují celý obsah svého počítače někam na externí disk a nazývají to záloha. Ano, na ty, co data ukládají raděj i vícekrát, a pak mají počítač přehlcený duplicitními daty.

Zkrátka asi na každého z nás, protože jen opravdu málo lidí se o svou IT techniku stará skutečně precizně. A takový člověk musí jednou za čas sednout, posbírat všechny externí disky, paměťové karty a flash disky a udělat si v nich pořádek. Vzít staré zálohy, a zálohy záloh, zálohy zálohy záloh, a buďto smazat, případně zaktualizovat. Vzhledem k tomu, že místa na disku je vždycky nedostatek, tak zálohy jsou stejně nekompletní a případně končí slovy: „no co, tak fotky jsem zálohoval loni a tak v nejhorším přijdu o fotky za letošek“.

Disketo neřeší žádný z uvedených problémů, to říkám rovnou. Ale může vám s nimi alespoň pomoct. Pomocí disketa si totiž můžete vyhledat
(a to je taky vlastně jediné, co disketo umí) různé soubory a složky podle různých kritérií.

A teď trochu techničtěji …

Aby člověk mohl disketo požívat musí se nejdříve ujasnit některé technické záležitosti. Disketo totiž původně tak trochu vzniklo pro programátory, protože některé věci si zkrátka naprogramovat musíte vy, i když chcete aplikaci jen používat. Ale v základu jej určitě může ovládat i trochu víc technicky zdatný uživatel.

Disketo je totiž kromě toho hodně orientován na linuxové operační systémy. To znamená jednak to, že se spouští z příkazové řádky, ale také to, že se nesnaží problémy vyřešit přímo, ale poskytnout data ve strojovém formátu, aby je mohly zpracovat další unixové nástroje jako např. less, grep, sed, find – nebo třeba i excel.

V neposlední řadě, pořád je disketo také programátorská platforma – chcete-li – knihovna, kterou je možné použít a dále její funkcionalitu rozvíjet. V takovém případě se očekává skutečně aktivní znalost Perlu. Ano, Perlu!

Základní myšlenka

Celé disketo totiž stojí na tom, že pro vyhledávání „problémových“ souborů či složek je třeba disketu říct, co hledáte. Na úvod třeba všechny složky, které obsahují fotky. Dále například všechny složky, které v názvu obsahují záloha a obsahují více než 90% shodných souborů. Nebo všechny páry složek, které mají alespoň jeden (dva, tři, …) společné wordovské dokumenty. A nebo prostě a jednoduše všechny složky, ze všemožných disků, flashek, cloudů a paměťovek, které obsahují něco, co se týká bakalářky.

Jak toho dosáhnout? Jednoduše a přitom složitě. Disketo toho umí relativně dost, ale je potřeba mu říct, co přesně je potřeba, aby našel. Na začátku (resp. na konci, ale k tomu se dostaneme) je vždycky seznam tzv. kořenových složek. Tedy složek, které chcete prohledávat. V praxi to většinou jsou přímo kořenové složky všech disků či uložišť (tj. na Windows C:\, D:\ a podob.). Samozřejmě, pokud hledáte třeba všechny fotky z léta 2016, asi nebudete nechávat disketo prohledat celý počítač, bohatě postačí jen Obrázky\fotky\.

Výstup z disketa může být zobrazen třeba ve formě adresářového stromu

Dalším krokem, je potřeba ujasnit si, co vlastně hledám. Hledám složky podle názvu? Hledám složky s určitými soubory? Hledám duplicity? A nebo ještě něco jiného? Operace je samozřejmě možné kombinovat. A k tomu slouží tzv. disketo skripty.

Disketo skripty

Disketo skript pak není nic jiného, než seznam právě těchto operací, příkazů, úkolů. Tak například příkaz filter_directories_of_same_name ze seznamu všech složek vyškrtne ty, které jsou v něm jen jednou. Jinými slovy, nechá jen ty složky, které jsou v uložišti dvakrát. Samozřejmě, asi bude vhodné nejdřív vybrat jen složky, které nás zajímají, tedy: filter_directories_by_pattern.

Tento příkaz vyžaduje uvést, jaké složky se mají ponechat a jaké vyhodit – na základě názvu, pochopitelně. Tedy například "fotky", "škola" nebo "zaloha". Je také možné uvést $$, v takovém případě bude hodnota zadána až při spuštění. To se hodí pro opakovatelně použitelné disketo skripty s jinak stejnou konfigurací.

Na závěr je slušnost přeživší složky vypsat – tedy příkaz print_directories_simply. Výsledný skript by pak vypadal následovně (první a druhý příkaz byly prohozeny, je rozumné nejdříve vyřadit složky, které nepasují názvem, až pak ty, které se neopakují):

Takto připravený skript uložíme do souboru, třeba slozky.ds a můžeme spustit. Protože obsahuje jedenkrát $$, bude při spuštění vyžadovat zadání jedné hodnoty – vzoru pro filtrování složek.

Spouštění

Disketo se spouští pomocí tzv. interpretu disketo skriptů, tedy prográmku run-disketo-script.pl. Jeho použití je následující:

Jeho prvním argumentem je název (cesta) souboru disketo skriptu. Následují argumenty skriptu a na konci je pak seznam (kořenových) složek, které má disketo prohledávat.

Vezměme si náš disketo skript slozky.ds. Budeme chtít prohledat složky skola a zaloha, a hledat v nich všechny duplicitní složky s názvem statnice. Spuštění se provede následujícím příkazem:

Výstup bude následující:

Jak vidno, disketo nám vypsal spoustu informací. Pokud nás nezajímají informativní hlášky o průběhu (hodí se vědět, jak dlouho která operace probíhala, můžou to totiž být i hodiny), můžeme je skrýt přesměrováním standartního chybového výstupu do /dev/null:

Nyní už vidíme jen seznam tří složek, které mají v názvu (resp. v celé cestě) statnice a současně mají shodný název s některou z jiných (zde všechny tyto tři současně). Když zkusíme vyhledat prijmacky, dostaneme:

Samozřejmě, disketo vyhledává slovo od slova. Při vyhledávání statnice nenajde ani státnice ani statnicove-otazky. Obecně, s češtinou (ve smyslu diakritiky) bude mít disketo zřejmě nemalý problém. Za to se omlouvám, řešení by bylo komplikované.

Další funkce

Například následující disketo skript vyhledá všechny složky, které mají zvolený název, a které obsahují alespoň jeden wordovský dokument:

Abyste si nemuseli pamatovat, jaké hodnoty skript kde vyžaduje (obzvlášť, pokud bude skript vyžadovat parametrů více), příkaz ./run-disketo-script.pl dokumenty.ds (tedy zavolání disketa jen s názvem skriptu, bez dalších hodnot a složek) vám požadované argumenty vypíše:

Co dělá který příkaz a co znamená každý z jeho argumentů by mělo být poměrně intuitivní, takže k nim není dodávána žádná další dokumentace. Zájemci mohou konzultovat zdrojový kód modulu Disketo_Extras, kde jsou implementovány.

Pro opětovné ozkoušení, jestli jste uvedli správné hodnoty lze použít přepínač --dry-run. Ten, klasicky, spustí disketo skript s reálnými hodnotami (ať už přímo ze skriptu nebo zadané při spuštění), ale nebude prohledávat disk (což ušetří čas). Tedy:

Pokud jej necháme skutečně proběhnout (tj. bez --dry-run), vypíše nám něco následujícího:

Jak vidíte, skutečně nám vypsal všechny (složky i podsložky), které v názvu obsahují otazky (a přitom obsahují alespoň jeden dokument *.docx).

Pár poznámek

Do disketo skriptů lze vkládat komentáře. Nijak neobvykle, řádek začínající # je ignorován až do svého konce.

Přepínač --dry-run už jsem zmínil. Vypíše, jaké příkazy disketo provede a s jakými hodnotami. Seznam všech příkazů a jejich parametrů se vypíše pomocí příkazu./run-disketo-script.pl --list-functions . Bohužel, nechtělo se mi psát se s dokumentací, takže případné informace o to, co patřičný příkaz dělá, vás odkážu na modul Disketo_Extras.

Disketo ve většině případů pracuje pouze s názvem souborů či složek. Předpokládá totiž, že chceme-li hledat složky s excelovskými tabulkami, budeme hledat soubory s příponou xls nebo xlsx, při hledání fotek jpg a podob.

S tím souvisí – pokud je některý z parametrů nazván pattern, pak ve skutečnosti očekává regulérní výraz, navíc case sensitivní, tedy rozlišující velká a malá písmena. Takže např. pro vyhledání fotek (malými nebo velkými písmeny) je třeba použít [fF][oO][tT][kK][yY] popř. (fotky)|(FOTKY). Pro vyhledání „fotky nebo foto“ pak třeba fot(o|ky).

Pokud se regulérní výrazy neznáte, mělo by být možné použít namísto nich běžný text. Je tedy třeba akorát hlídat si malá a velká písmena a vyhnout se použití speciálních znaků (závorky, pomlčky) (nebo před každý z nich dát zpětné lomítko). Pokud chcete vzor, který splňuje každý text, použijte např. (.*) (to se hodí, pokud je pro vás některý z filtrů zbytečný, nebo jej chcete jen rychle deaktivovat).

Obdobně, parametry jako printer nebo matcher musí být perlovské subrutiny, tedy funkce. Díky tomu je možné doprogramovat prakticky libovolný způsob, jak porovnávat, vypisovat, či vyhledávat soubory a složky. Tak například následující skript:

Vypíše:

Na závěr už snad jen – v instalaci disketa se nachází adresář scripts, který obsahuje pár základních skriptů. Asi nebudou úplně pro přímé použití, nicméně třeba poslouží jako inspirace.

Kde a jak?

Disketo najdete na mém GitHubu, není to samostatný repozitář, je součástí mého projektíku shell-utils.

Disketo – kromě perlu, pochopitelně, nemá žádné jiné závislosti nebo požadavky. Stačí mít jen v počítači perl a spustit ./run-disketo-script.pl, popř. perl run-disketo-script.pl.

V samostatném článku pak ukážu, jak si s pomocí disketa udělat pořádek ve fotkách.

Moje prográmky III (C*)

Po veleúspěšných dílech Moje prográmky I – Pascal a Moje prográmky II – Delphi příchází Moje prográmky III, s nyní už trochu rozsáhlejšími a v rodině jazyka C (C a C++) psanými prográmky.

A protože jsem fanda linuxu a tak nějak se mi nechtělo oficiálně distribuovat svoje kódy, tak jsem vytvořil Samorozbalovací instalátor pro Linux. Z následujícího rozbalovacího seznamu si pouze vyberete požadovaný program, stáhne se vám skript, kterému pouze nastavíte práva a spustíte a on se už o vše postará:

Instalátor má i nápovědu, volá se standartními přepínači:

Nainstalovat program:

 

Samozřejmě zde ovšem dodávám mou oblíbenou tabulku všech programů, jako vždy s krátkým popiskem funkce onoho programu.

Generátor mocnin dvojky

Výstupem jsou soubory s binárním, hexadecimálním a především dekadickým zápisem čísla 2EXP, kde EXP si volíte a v závislosti na vaší výpočetní kapacitě se může pohybovat klidně v řádech desetitisíců.

celý článek

 

Pascalův trojúhelník, binomická věta, kombinační čísla

Program využívá zajímavých vlastností Pascalova trojúhelníka a díky nim snadno mimo samotný trojúhelník může vypisovat také kombianční čísla a binomické rozvoje. Je obsluhován jednoduchou příkazovou řádkou.
Instalačka pro Linux ZDE
Zdrojový kód

martlin’s simple console ascii art generator 1 a 1.2

Programu jako argument předáte název bitmapy, ona vám ho vykreslí v ASCII znacích, které si také můžete zadat, nebo použije výchozí.

celý článek

 

Parser aritmetických výrazů

Závěrečný projekt do Programování pro fyziky, dá se říci pokročilejší konzolová kalkulačka. V tuto chvíli má aplikace jen minimální uživatelské rozhraní, takže je v praxi téměř nepoužitelná, slouží především k nastudování jednoho z algoritmů parsování.
Instalačka pro Linux ZDE

celý článek

 

Anny’s Lab

Velmi jednoduchá konzolová bludišťovka, napsaná přes prázdniny v C++. Program je poněkud rozsáhlejší, takže bohužel nejde použít samoinstalátor.

celý článek

 

To je zatím vše.

Bash a shellové skripty v Linuxu

Pro pochopení, Bash je jeden z několik unixových shellů. Myslím, že ten nejrozšířenější a nejznámější. Podporuje i některé konstrukce, které z něj však dělají plnohodnotný programovací jazyk určený k psaní skriptů (kromě samotných příkazú). Unixových skriptů. Hlavu bych za to nedal, ale je to něco jako DOSovské BAT soubory. Stejně jako ty DOSovské skripty lze i ty Unixácké snadno spouštět (a samozřejmě také upravovat) a oproti jiným programovacím jazykům umožňují rejpat se v celém počítači, od souborů na pevném disku až po datum a čas. Bashové skripty jsou totiž primárně tvořeny většinou linuxovými příkazy.

Takovéto skripty by nám v celku k ničemu nebyly (asi těžko bychom vytvářeli soubor s názvem „Zadejte váš věk:“ a pak jej pomocí příkazu ls (výpis obsahu adresáře) nechali vypsat na obrazovku, jakožto oznámení obsluze, aby zadala svůj věk), tak nám kromě pánaboha při tvorbě skriptů pomáhají základní příkazy jazyka Bash. Toto není návod na psaní skriptů (toho je plný internet – obzvláště linuxácké portály) a tak zmíním například příkaz echo (=ozvěna; co mu zadáte jako parametr, to vám vrátí na obrazovku – klasický vypisovací příkaz) a jeho protějškem je příkaz read. Tyto příkazy se nastavují klasickými „pomlčkovými“ parametry, takže echo -n "Jméno: " díky prvnímu parametru po vypsání textu neprovede odřádkování.

Pořád bychom toho asi ani moc nenapsali. Samozřejmě, že Bash umí i podmínky a cykly. Zajímavě funguje příkaz if – parametr podmínka se nevkládá do kulaté závorky jako v Céčku, ale do hranaté (a navíc je ohraničen mezerami). Na tom by nebylo nic až tak moc zvláštní, avšak zvláštností je to, že ona hranatá závorka je ve skutečnosti program (myslím, že ve skutečnosti je to symbolický odkaz na program test, ale to vcelku nehraje roli) jemuž dáváme parametry (například [ -e "Martin.txt" ] zjištuje, jestli soubor Martin.txt existuje.

Kromě těchto standartních vlastností umí i další. Kupříkladu velice šikovnou pomůckou jsou roury. Ty umí vzít výstup jednoho příkazu a poslat je rourou na vstup druhého. Takže příkazem calc provedeme nějaký složitější výpočet (Bash umí jen základní pětici matematických operací, zbytek se musí řešit jinak, což je celkem nevýhoda) a výsledek tohoto výpočtu pošleme na vstup mkdir a on nám vytvoří složku s názvem o dané číselné hodnotě jakoby v jednom příkazu a bez nějakého ukládání do proměnných. Naprosto úžasnou funkcí bashe je však snadné ukládání do souborů. Prostě výstup souboru přesměrujete do ‚názvu souboru‘ a ono to tam pošle. Nejsou třeba žádné inicializace souborů, kontroly existence a tak (ale musíte mít k zápisu do souboru patřičná přístupová práva).

Je třeba si uvědomit, že v linuxu to buďto vyjde a nebo ne a pak je to v … na konci roury (obrazně řečeno). Každý příkaz vždy vrací číselnou hodnotu. Je-li nulová, pak vše proběhlo v pořádku. Je-li nenulová, pak byla někde chyba. K chybě patří i třeba překlep v zápisu parametrů, takže když při zápisu podmínky do hranaté závorky zapomenete oddělit název příkazu [ od jeho parametrů, vyhodnotí podmínku vždy jako nepravdivou, což programátorovi může ze začátku dělat problémy.

Abych to nějak shrnul, v Bashi se člověk opravdu vyblbne. Kdo je magor jako já, může si klidně napsat skript, který po připojení foťáku k počítači jej automaticky namountuje ( mount – příkaz, který po hardwarovém připojení zařízení jej připojí i softwarově), vytvoří v počítači složku s názvem dnešního data a zkopíruje tam všechny nové fotky a přitom vám bude v průběhu kopírování zobrazovat kolik ještě procent a času zbývá.

Napříkald můj kamarád si vytvořil program, který odešle zadaná klíčová slova na images.google, stáhne jeden z nelzeneách obrázků a nastaví vám jej jako pozadí plochy. Skript má 3 řádky (1.- odeslání požadavku na images.google.cz a vybrání obrázku, 2.-stažení obrázku, nastavení jako pozadí).

Já osobně v Bashi programuji raděj, než třeba v klasickém C. Jeden z důvodů je ten, že skripty není třeba kompilovat, jsou přímo připraveny ke spuštění, a druhak díky tomu, že syntaktické chyby, které vám kompilátor (myslím ten klasický, konzolový – gcc ) vyplivne jenom jako číslo řádku a stručný popis, kterému stejně málokdo porozumí. V Bashi se vám tato hláška objeví až přímo za chodu, takže přesně víte občas i víte, kde chybu hledat.

Bash prostě dokáže ušetřit čas, je to jazyk, který se hodí, prostě si můžete pěkně pohrát s celým systémem a to my Linuxáci máme přece tak rádi!

Zde je článek o mém skriptu C write ‚n‘ run, vývojovém prostředí pro jazyk C v textové konzoli.

SuperTuxKart

logo Supertuxkart
logo Supertuxkart

SuperTuxKart je velice zábavná hra, jak již vyplývá z jejího názvu, vytvořená pro operační systém Linux. Jednou větou řečeno, jedná se o super hru, ve které jezdí (mimo jiné) Tux v malých motokárách (anglicky kart).

Menu výběru trati
Menu výběru trati

Trať Racetrack
Trať Racetrack

Co více psát? Na hře, a obecně na veškeré linuxové tvorbě se mi líbí takové teplo, které na mě sálá. Všechno je takové pozitivní, příjemné, milé, a když se má stát něco špatného, tak i to v sobě má něco dobrého (toto můžete pozorovat i u Simutrans). Když mě předjede Mozilla, nebo EvilTux, tak bych normálně nadával, ale u SupertuxKart si řeknu, no dobře, hold tudle trať neumím ale s úsměvem na tváři. Úsměv mi mrzl, až když jsem nemohl nějaký level udělat i několik hodin, ale to jen proto, že jsem strašný nervák a i nepatrná blbost mě dokáže k smrti vytočit.

Ukázkové video

Navíc se tvůrcům hry podařilo skloubit strašně moc odvětví dohromady, o což já se marně snažím velmi dlouho. Stejně tak, jak si můžete zajet závod na klasickém závodním okruhu, tak se také můžete projet v amazonském pralese, na hřbitově, na mléčné dráze, na pláži nebo jen na zasnežené hoře. Navštívíte také neznámou planetu XR591, kaňón, nebo dálniční přivaděč.

Trať Snow mountain. Jste-li v nouzi nejvyšší, zavolejte si Tuxe na pomoc!
Trať Snow mountain. Jste-li v nouzi nejvyšší, zavolejte si Tuxe na pomoc!

Trať Mléčná dráha
Trať Mléčná dráha

Jak jsem psal, závodiště jsou opravdu komplexně zaměřená, od jednoduchých okruhů, až po opravdu těžké a dlouhé klikaté tratě.

Nechybí ani power-upy ve formě dárků, které vám například umožní vrhnout bowlingovou kouli s nadějí, že zasáhne některého ze soupeřů, nejrychlejšímu soupeři nasadit na pár sekund kotvu, nebo vypustit kalužku zvláštní růžové lepkavé kapaliny, které každého, kdo přes ni přejede zbrzdí na minimální rychlost.

Trať: Pevnost magma. GNU se dívá na jeden z portrétů krále Tuxe
Trať Pevnost magma. GNU se dívá na jeden z portrétů krále Tuxe, kterými je celá pevnost vyzdobena

A vítězem se stává... Tučňák!
A vítězem se stává... Tučňák!

Kromě dárečků můžete také sebrat slupku od banánu, která na vás kupříkladu umístí časovanou bombu, nebo onu kotvu nasadí vám. Nechybí ani láhve s nitrem.

Prostě SupertuxKart je pro mě skvělou relaxací. Za poslechu velice zajímavé hudby, a shlédnutí jednoduché (až primitivní) grafiky se občas se zasním, že bych třeba taky někdy mohl naprogramovat podobnou hru.

Video z mé oblíbené trati – Pevnost Magma

Pouze bych dodal, že SuperTuxKart najdete v repozitářích software Ubuntu a dokonce existuje i verze pro Windows, ale tak se mi tak příšerně seká, že jsem na ní neujel ani jedno kolo a šla do koše.

Nebojte se příkazové řádky

  1. K čemu je příkazová řádka?
  2. Příklad první – instalace programu
  3. Příklad druhý – složité nastavení
  4. Porovnání Terminálu a Grafického prostředího v praxi
  5. Další „programy“ a jejich protějšky
  6. Pár slov na závěr

Příkazová řádka je nedílnou součástí Unixových operačních systémů. Mnoho lidí však stále tvrdí, že to k ničemu. Oproti Windows, kde příkazová řádka slouží jen jako doplnění funkce a málokdo ji používá, Linuxová příkazová řádka je silný pilíř, na kterém stojí celý operační systém.

Dalším pozitivem Shellu (tak se říká linuxové příkazové řádce) je ten fakt, že pokud máte například linuxový server (a že jich je!), takže nač zbytečně plýtvat jeho výkonem pro grafické prostředí, které stejně použijete třeba jen jednou za týden, takže ani není snaha některé serverové příkazy přetvářet do grafického režimu (a některé ani nejdou).

Příklad první – instalace programu

Někde, myslím, že někde na stránkách Ubuntu, jsem našel velice zajímavý argument pro příkazovou řádku. Představte si, že si chcete nainstalovat nějaký program. Spustíte Centrum Softwaru, naťukáte název programu, počkáte, až se vám najde, kliknete na Nainstalovat, zadáte heslo a už to jede.

Nebo kliknete na ikonku Terminálu (já jako správný linuxák ji mám vždy po ruce na hlavním panelu, avšak už ji nepoužívám, protože jsem se naučil klávesovou zkratku Ctr+Alt+T) a napíšete:

Nebo, pokud jste hodně líní, tak si ten příkaz prostě zkopírujete z toho článku, který právě čtete a z pravidla tam někde bude. Zmáčknete Enter, a zadáte heslo a už to jede.

Kolik času jste ušetřili?

Příklad druhý – složité nastavení

Ale opusťme obyčejné stahování a instalaci programu. Představme si něco složitějšího. Co kdybychom operací podobných té předchozí museli udělat víc za sebou, třeba 6 (například nastavit něco, nastavit něco jiného, to první přenastavit, restartovat to, zkontrolovat to, vrátit to druhé do původního stavu)?

Klik, klik, klik ,klik, … po desítkách kliknutí bude hotovo. Když si otevřete terminál, vložíte tam postupně všechny ty požadované příkazy (buďto jste si je zkopírovali z toho návodu na netu, nebo je prostě znáte) a o tom, jestli to budete mít hotové za 20 nebo 30 sekund rozhoduje pouze, jak rychle umíte psát.

Porovnání Terminálu a Grafického prostředí v praxi

Krásou linovýxh příkazů je fakt, že velká část základních programů v grafickém prostředí má své předchůdce i v příkazové řádce. Zde máte několik nejtypičtějších příkladů:

Centrum Software Ubuntu vs. Aptitude

Na obrázku dole vidíme náš první probíraný přiklad. Jak v grafickém režimu v Centru software pro Ubuntu (kdo nepoznal, je to vlevo) i v jeho konzolovém protějšku Aptitude (vpravo) jsem vyhledal „program“ (ona je to ve skutečnosti hra 🙂 SuperTuxKart. Můžete vidět, že text je naprosto stejný (až na grafickou adaptaci – jiné písmo, odrážky a tak).

Aptidude a Centrum software Ubuntu
Aptidude a Centrum software Ubuntu

Sledování systému vs. Top

Další ukázkovou dvojicí jsem vybral velmi podstatnou část každého operačního systému, a to konkrétně pro Ubuntu program Sledování systému. Program mimo jiné vypisuje seznam všech běžících procesů. Tuto funkci nese také konzolový program Top . Nevím sice co to znamená (buďto se jmenuje podle hlavičky nahoře, já osobně bych řekl, že top znamená table of processes, avšak ani jedno se nepotvrdilo, takže prostě top), ale používám jej když si omylem zasekám počítač a potřebuje onen problematický program ukončit. Tak si najdu v top jeho pid (process ID) a pak ho kill nu.

Top a Sledování systému
Top a Sledování systému

Mozilla/5.0 vs. W3m

Další, velmi významný program je internetový prohlížeč. Kromě prohlížeče Mozilla/5.0, který používáte vy, existují i další. Mezi nimi i třeba konzolový prohlížeč w3m . Na obrázku dole můžete vidět část této stránky (starší verzi) zobrazené právě ve w3m.

Samozřejmě, že zásadní nevýhodou konzolových prohlížečů je většinou totální ignorace jak kaskádových stylů, tak i javascriptů ( a dalších, jako obrázky, objekty, …).

Pokud však jen potřebujete rychle najít nějakou informaci na některé stránce jejíž adresu znáte, tak místo spouštění třeba Mozilly, datlení adresy do adresního řádku a pak teprve študovali, stisknete Ctrl+Alt+T, napíšete w3m < adresa >, dáte Enter a je hotovo.

W3m a tato stránka
W3m a tato stránka

Další „programy“ a jejich protějšky

Datum a čas

Naprosto úžasná dvojce příkazů, kterou pravděpodobně používá každý, je date a cal. Po instalaci Ubuntu máte na horním panelu vpravo program Hodiny, který zobrazuje datum a čas ( v trochu civilizovanější formě než onen příkaz date).

Když na něj kliknete, zobrazí se kalendář na celý tento měsíc. Tuto funkci zastává program cal (od slova calender). Pokud však napíšete příkaz cal <?php echo StrFTime("%Y",Time()); ?>, program vám zobrazí v krásné tabulce (3 x 4 měsíců) kalendář na celý rok.

Můžete si také zobrazit, třeba, který den začne prosinec 2046, nebo si zjistit, že Mistr Jan Hus byl upálen → v sobotu (pro neznalce 6. 7. 1415, tedy cal 7 1415). A právě pro tyto účely jej používám, neboť když si rozkliknu program Hodiny, a chtěl bych se podívat právě na onoho mistra Jana Husa, musel bych se k němu prostě proklikat (a že by to bylo kliků).

Příkazy date a cal a Hodiny
Příkazy date a cal a Hodiny

Vypnutí počítače

Mou oblíbenou hříčkou je pak vypínání. Vypnout počítač lze různými způsoby. Od Harwarového vytržení ze zásuvky nebo vytažení baterie notebooku přes stisk/podržení tlačítka na pc, až po kliknutí na Vypnout… A nebyl by to Linux, kdyby na to neměl příkaz. Má jich dokonce několik: < poweroff, shutdown nebo třeba halt. Já obvykle (večer) než noťas vypínám jej ještě nechám (samozřejmě kvůli facebooku) nějakou tu minutku zapnutý a ještě něco kutím po bytě. Poté už ani nesedám na židli, a vzhledem k tomu, že ze stoje se jednak hůře manipuluje s myší a druhak je na LCD blbě vidět, tak obvykle jen spustím terminál kombinací Ctrl+Alt+T a napíšu příkaz sudo poweroff (načež zadám heslo) a počítač se vypne.

Úplně stejnou funkci provede kliknutí na Vypnout… v nabídce Appletu upozornění pro sezení (defaultně úplně vpravo nahoře). Když na to kliknete, po potvrzení (což nahrazuje zadání hesla – aby si ten počítač nemohl vypnout jen tak leckdo a to bez předchozího uložení rozpracované práce) se prostě provede příkaz poweroff.

Jak to tak bývá, samotné vypínací příkazy nám poskytují zpravidla víc funkcí než obyčejné 1 kliknutí. Šikovným je v této situaci napřiklad zápis shutdown -h +15 – počítač vypne za 15 minut (můžete tak někoho velice nemile překvipit ;-)).

Poweroff a Vypnutí přes Applet upozornění pro sezení
Poweroff a Vypnutí přes Applet upozornění pro sezení

Zavření terminálu

Poslední příkaz, který bych zmínil, je velice prostý: exit. Prostě opustí, ukončí (v grafickém prostředí se to projeví zavřením okna) tento terminál. Je to substituce za kliknutí na křížek v rohu, případně jiný způsob ukončení, jako je Alt+F4, nebo třeba sebevražedný příkaz kill < PID procesu gnome-terminal >.

Tento příkaz používám velmi často, jednak když už jsem namlátil do klávesnice všechny ty příkazy, tak než abych pak tam myší najížděl na onen křížek, prostě napíšu exit, a druhak se tento způsob ukončování terminálu doporučuje jako jako jediný validní způsob ukončení terminálu.

Nejlepším kamarádem přikazu exit je příkaz logout. Zatímco exit se používá v Terminálu, příkaz logout vám schramtsne většinou jen klasická dálnopisová konzola (Ctr+Alt+F<1 až 6>), jinak mají stejnou funkci.

Exit a klasické zavření
Exit a klasické zavření

Pár slov na závěr

Kromě toho, že umět pracovat s příkazovou řádkou je vcelku machrovinka, tak vám to může pomoct i například, když vám spadne systém (třeba kvůli přetížení) a musíte nouzově zachraňovat a zálohovat přes konzoli. Kromě toho bych také řekl, pro starší stroje, mezi jejichž vlastníky se hrdě hlásím, může sloužit ke zrychlení práce. Na co je mi graficky perfektní program pro zobrazení využití paměti, když mi bohatě stačí jedno číslo, které si najdu třeba ve výstupu příkazu free -mos 1?

Navíc, jak jsem psal ze začátku, jsou počítače (především servery), kde se ničím jiným než s textovou konzolí nesetkáte. A pokud s počítačem alespoň trochu umíte, je dobré se naučit i používat příkazovou řádku.

A to se ani nezmiňuji o psaní shellových skriptů, neboť jak nám na výšce dokázali, je to získáte tím opravdu velmi mocný nástroj:

Příkazy – programy a prográmky
+
Interní příkazy jazyka Bash
+
přesměrování vstupů a výstupů, roury
+
soubory
=
COKOLIV!

Windows XP vs. Ubuntu 10.04

Zapínám notebook. Po uvítacím logu COMPAQ se mi zobrazí bootovaci menu. Většinou už jsem předem rozhodnut, ale přece jen chvíli zauvažuji, než zvolím vhodný operační systém pro mou následující práci. Pokud bych se do 10 sekund nerozhodl, padá volba automaticky na jednu z nepopulárnějších Linuxových distribucí – Ubuntu (10.04). A právě v tomto článku se pokusím vám popsat, proč kurzor nemám nastaven na „druhém“ (ve skutečnosti asi na 6.) řádku, tedy Microsoft Windows XP Profesional.

Ubuntu.
Ubuntu - Linux for Human Beings

První důvod, který bych tu nijak zvlášť nerozebíral je ten, že po nainstalování Ubuntu se mi nastavilo jako primární operační systém a mě se nechtělo měnit. Proč také? Ale ten druhý…

Před pár dny (leden 2011) mě napadla poměrně jednoduchá a názorná substituce pro ukázku obou, nejpoužívanějších operačních systémů. Začnu tedy tím známějším.

Microsoft Windows

logo Windows
logo Windows

Operační systém Mircosoft Windows si můžete představit jako byt. Za pár tisíc si koupíte byt, který budete užívat, stejně jako operační systém. Po nastěhování (operačního systému na disk) máte ve vašem jinak prázdném bytě něco už předchystané, neboť to spadá k přinejmenším k základnímu vybavení. Stejně tak jak po nastěhování do vašeho nového bytu zjišťujete, že v předsíni máte vestavěnou vestavnou skříň, u oken radiátory, a v koupelně vanu, tak stejně tak zjišťujete, že máte najednou v počítači Internet Explorer, Windows media player, či Windows Life messenger. Pokrčíte tedy rameny, neboť víte, že programy, které tam máte jsou nezbytné. Když se však rozhlédnete, tak zjišťujete že kromě něčeho vestavěného v tom bytě není už v podstatě nic.

Kancelářský balíček, který vyrábí ta firma, od které máte být, by ve vaší pracovně rozhodně neměl chybět. Zjišťujete však, že vás vyjde na skoro tolik, jako celý být. Nicméně pak ještě od společnosti Electronics Arts koupíte nějaká ta autíčka, aby si děti měly s čím hrát a nějaký ten Photoshop, aby si měly v čem upravovat profilovky na facebook. Takže už máte v bytě nějaký ten základní nábytek. „Ale ještě by to necho chtělo – jasné, chce to novou tapetu (plochy).“ Hned to vypadá lépe, ale pořád vám tu necho chybí. Velké společnosti už vám nepomohou, a tak se vydáte do do města. „To je ono, tady rozdávají něco zadarmo. Květináčky, stolečky, lampičky, to je přesně ono. Výborně, stolička, co ještě? Kobereček! A co dál? Ještě si vemu Adobe Reader, a k němu taky PDF Creator. Nesmím zapomenout taky na WinRar. A co s tou vanou? Tady vidím sprchové kouty Mozilla. Ten model Firefox se mi líbí, tak si ho vezmu.“ Pokud se vám bude chtít, tak tu vanu vybouráte a vyhodíte, ale většinou si ji tam lidé nechávají.

plocha Windows
Výchozí plocha čerstvě po nainstalování Windows XP

Tak si tak spokojeně žijete v tom svém bytečku. Některé komponenty, které používáte jsou doslova ruční práce – prostě nějaký programátor sedl, a vyprodukoval nějakou jednoduchou blbost, jako kalendář, který vám ukazuje, kdo má dnes svátek a podobně.
Po čase se vám toho všelijakého softwarového haraburdí různých výrobců, firem, funkcí a principů nahromadí tolik, že si budete muset sehnat nějaký čistič (obvykle taky bývá zadarmo), aby vám tam udělal pořádek. Jenže semtam nějaký ten program spadne a rozbije se. Čistič sice vyhodí ty celé kusy, ale ty drobné střípky zůstanou někde v koutě. Nehledě na to, že si občas domů donesete buďto nějakou blbost, kterou vám vnutili třeba za účelem reklamy (různé vzorky, vzorečky, a další dema a shareware). No a samozřejmě čistič, který má tomuto bránit, to považuje za něco, co používáte a nevyhodí to. Řešení je buďto pořídit si lepší, placený čistič, nebo to nejnutnější odstěhovat na víkend na chatu, flashku a podob. a z bytu všechno vyházet, vymalovat, naformátovat, a všechno znovu nastěhovat (dá se říci metoda Noemova Archa).

Ubuntu

logo Ubuntu
logo Ubuntu

Oproti tomu Ubuntu, si můžete představit, jako auto. Přijdete a dostanete auto. Kromě toho, že ho dostanete zadarmo, tak jej klidně můžete „stáhnout z internetu“, tedy dodají vám jej až do domů. V okamžiku, kdy vám jej přistaví před dům je auto po pár formalitách, jako je natankování nádrže, nastavení jazyka, napsání seznamu uživatelů a samotné předání klíčků, připravené k jízdě bez sebemenších problémů. V autě je opravdu všechno co potřebujete – motor, karosérie, sedačky, světla, program pro grafiku – Gimp, nějaký ten kecálek (Empathy) a tak dále.

Ubuntu, respektive samotné linuxové jádro, je totiž vlastně motor (souhlasíte jistě se mnou, že bez motoru by to nebylo auto) obalený fůrou dodatečných komponent počínaje karosérií (grafické prostředí), koly (ovladače) přes klimatizaci (kancelářský balíček OpenOffice) až po např. zadní stěrač (BitTorrent). Vy, samozřejmě, v okamžiku, kdy si auto koupíte, tak ho máte v nějaké výbavě (výbavy se mění s „distribucemi“ – Ubuntu, Kubuntu, …). Například v autě Ubuntu sice nemáte parkovacího asistenta, za to tam ale máte vyhřívané sedačky.

Plocha Ubuntu
Výchozí plocha čerstvě po nainstalování Ubuntu 10.04

Ale co je důležité, pokud by jste toho parkovacího asistenta mermomocí chtěli, tak není nic jednoduššího, než zavolat na technickou, jestli by vám ho neposlali. V Ubuntu nikam nemusíte volat, stačí prostě kliknout na „Centrum softwaru pro Ubuntu“ a vyťukat název hledané komponenty, která se vám ihned stáhne a pravděpodobně i namontuje do toho vašeho autíčka. Na vás už je pak jenom seřízení nastavení, jako např. nastavení teploty. Stejně tak, pokud si budete myslet, že parkovacího asistenta vůbec nepoužíváte, že by jste si jej vymontovali, tak není problém. Dokonce, pokud se vám třeba nebude líbit karosérie, tak by neměl být problém ani s ní (i když jsem to ještě nikdy nedělal). Kdyby jste chtěli, můžete si karoserii odmontovat úplně a pracovat jen v příkazové řádce. V tom případě vám ovšem bude například klimatizace (nebo grafický program Gimp) k ničemu :-).

Díky tomuto systému se vám v počítači nehromadí žádný nepořádek, a když se vám náhodou některá komponenta pokazí, tak si ji prostě necháte poslat znovu, reinstalujete ji. Dokonce, pokud se vám něco nezdá, tak vám mohou umožnit si tu komponentu upravit dle vašich potřeb a dát k dispozici ostatním uživatelům vaší vylepšenou verzi (tomu se říká open-source).

Shrnutí

Tux, symbol Linuxu vyjadřuje svůj názor na Windows
Tux, symbol Linuxu vyjadřuje svůj názor na Windows

Já bych prostě řekl, že Linux má něco do sebe, připadá mi logičtější a spořádanější než Windows, kde si každý dělá co chce. V Linuxu spolu programy spolupracují, protože je všechny vyvíjí jedna komunita lidí, což je nesporná výhoda, ale i nevýhoda (když spadne jeden program, hroutí se celý systém jak domeček z karet).

Abych byl upřímný, Moje XPéčka v porovnání s Lucid Lynx mi přijdou určitým způsobem stabilnější, padají méně. Jenže zkuste si na téměř 10 let starém stroji hrát se složitými vektorovými obrazy! Systém se uživateli snaží vyhovět, takže je schopný se třeba na 10 minut zaseknout nad operací, kterou mu zadal, bez ohledu na to, že na to nemá, a systém začne ukončovat různé procesy, aby získal nějaké to procento CPU navíc.

U Windows, pokud by takováto situace nastala, máte možnost tyto programy poukončovat přes Správce úloh, nebo počítač nemilosrdně restartovat. U Linuxu se znalejší uživatel přepne do příkazové řádky a za současného provádění jiné činnosti (například úklid na stole), neboť je počítač stále velmi vytížen a každá operace najednou trvá opravdu monohonásobně delší čas, může pracovat alespoň tam.

Ještě bych dodal fakt, že až na tyto stavy totálního vytížení mi jak XPéčka z roku 2001 tak Lucid Lynx z dubnu 2010 (Ubuntu 10.04) jedou téměř stejně rychle. A nedokáži si představit, jak by asi na mém notebooku jely např. sedmičky, které jsou o půl roku starší než ono Ubuntu.

Explore Ubuntu.
Like it?
Install it.
Love it!
ubuntu

Ubuntu je prostě změna, ale ne zase tak veliká, jak se může zdát. Netvrdím, že k lepšímu, ale myslím, že horší to určitě nebude. Podpoříte tím asi 2% menšinu.

Kdyby jste Ubuntu opravdu chtěli zkusit, prostě jděte na stránky Ubuntu – Ubuntu.cz → a stáhněte si ho.

Moje vývojové prostředí pro textovou konzoli linuxu

Začalo to takhle:

Ti bystřejší pochopili, že se jedná o programování v jazyce C. Ano, takto jsem začínal já programovat v Céčku.

Vzhledem k tomu, že mě v textové konzoli bavilo pracovat, neviděl jsem důvod proč si instalovat nějaké grafické vývojové prostředí. Avšak psát tyto příkazy pořád dokola mě po pár úpravách zdrojového kódu přestalo bavit, ale napadlo mě, že bych si na to mohl napsat skript. Skript prostě provedl výše napsané 4 příkazy a skončil. V případě potřeby jsem jej spustil znovu a znovu a znovu, doku nebyl prográmek hotov.

Když jsem to zabalil do cyklu (abych jej nemusel spouštět pořád dokola), bylo potřeba v určitý okamžik zeptat se uživatele, zda-li chce program ukončit. V tom se ve mně zrodila myšlenka jakéhosi ‚menu‘. Tam by si uživatel mohl zvolit nejen ukončení, ale také jednotlivé příkazy (editace, kompilace, spuštění). Kromě toho si mohl zvolit pracovní soubor, no a pomalu z toho začalo vznikat vývojové prostředí.

Díky jeho funkcím jsem jej nazval skromně C write ‚n‘ run (Céčko – napiš a spusť) a od té doby, jsem jej používal a příležitostně i poupravil o nové funkce.

Postupnými úpravami se však objevilo několik chyb, a navíc, při příchodu na vysokou v září 2011 jsem prošel vstupním kurzem Linuxu, kde jsem se dozvěděl kupu nových informací, které mě přivedly k tomu, abych si C-wnr napsal komplet znovu. Stalo se tak, a vzniklo C-write ‚n‘ run 2.


Stažení C write ‚n‘ run 2.1 (9,3kB)

Upozornění: 13. prosince 2011 v kolem 13. hodiny byla vydána verze 2.1, která odstraňuje problém kompilace matematických funkcí (kompilátor ‚neznal‘ funkce z knihovny math.h) přidáním parametru -lm.

 

 

Krásou C-wnr je však to, že pouhou změnou několika málo příkazů (v podstatě jen jednoho jediného a textové omáčky kolem) tak můžete získat vývojové prostředí pro jazyk Pascal:

Pascal-wnr-2 dodám, až jej budu mít vytvořený.

nebo Java-write ‚n‘ run:

také dodám později.