Batch

V dávných dobách, kdy světu ještě vládly střediskové počítače a uživatelům děrné štítky, nebylo dost dobře možné, aby každý jednotlivý uživatel byl "u toho", když se jeho úloha skutečně zpracovávala. Místo toho musel uživatel předem přesně stanovit, co a jak se má s jeho úlohou udělat, kde má tato úloha vzít svá vstupní data, co se má stát s jejími výstupními daty apod. Navíc musel toto své přání vyjádřit v takové formě, která by byla pro počítač srozumitelná - pomocí příkazů vhodného řídicího jazyka - a vše pak přidat k vlastní úloze a jejím datům. Tím vznikl celek, kterému se říkalo dávka (batch) a který mohl být zpracován v podstatě kdykoli, když k tomu byla vhodná příležitost. Obvykle se všechny připravené dávky řadily do front a zpracovávaly tehdy, až na ně došla řada. Takovémuto režimu se pak říkalo dávkové zpracování (batch processing).

Později, když velké střediskové počítače byly již vybaveny mnoha terminály a pracovaly současně na více úlohách v režimu tzv. sdílení času (time sharing), uživatel již mohl být "u toho". Prostřednictvím terminálu mohl interaktivně komunikovat jak se svou vlastní úlohou, tak i s operačním systémem, kterému mohl průběžně zadávat své příkazy. Často mu sice dlouho trvalo, než si rozmyslel, co vlastně chce, a než to počítači skutečně zadal - zvláště kdybychom rychlost reakce člověka měřili rychlostí počítače. Tomu to však příliš nevadilo, protože mezitím mohl plnou svou rychlostí pracovat na úlohách, které mu již dříve zadali jiní uživatelé.

Myšlenka předem si připravit příkazy pro operační systém a pak mu je předat všechny najednou však přetrvala zánik dávkového zpracování v jeho původní podobě.

Změnila se však motivace, kvůli které to uživatelé dělají, a částečně i související terminologie.

Jednou z možných motivací je snaha vyhnout se opakovanému vypisování dlouhých a málo mnemonických příkazů. Pro uživatele je jistě výhodnější, může-li si takovýto příkaz či celou skupinu na sebe navazujících příkazů připravit ve formě textového souboru a operačnímu systému pak pokaždé místo "skutečných" příkazů zadat tento soubor, ze kterého si operační systém své příkazy převezme již sám. Další možnou motivací je snaha zjednodušit práci běžným uživatelům - správce systému, systémový programátor či zkušenější uživatel může připravit takovýto soubor s příkazy pro operační systém a soubor zpřístupnit ostatním uživatelům. Ti pak mohou jeho prostřednictvím zadávat operačnímu systému provedení "předem připravených" akcí, aniž by se museli starat o význam a přesný formát příslušných příkazů, počet a tvar jejich parametrů atd. Tímto způsobem je vlastně možné vytvořit pro běžné uživatele zcela odlišný způsob práce v operačním systému, vybudovat pro ně mnohem komfortnější prostředí a odstínit je od mnoha detalů technického charakteru.

Skupině příkazů operačního systému, která slouží výše uvedenému účelu a má obvykle formu textového souboru, se v angličtině říká batch file (např. v prostředí MS-DOSu) nebo command file, případně shell script (např. v prostředí Unixu). Česky je asi nejvhodnější termín příkazový soubor, ev. skript (v Unixu).

Možnost vytvářet a používat příkazové soubory může být velmi mocným mechanismem. K tomu je ale potřeba, aby v rámci příkazového souboru bylo možné zajistit například opakování některých příkazů, volit další postup alternativně podle stavu určité podmínky, umožnit, aby příkazové soubory mohly samy mít parametry atd. Většina operačních systémů proto definuje celý řídicí jazyk, který je možné při sestavování příkazových souborů používat a který pak obsahuje např. příkazy podmíněného či nepodmíněného skoku, volání jiného příkazového souboru, možnost testování parametru příkazového souboru apod. Bohatost tohoto jazyka, a tím i možnosti příkazových souborů, jsou v různých operačních systémech samozřejmě různé. Velmi chudý je tento řídicí jazyk v MS-DOSu, velmi bohatý je naopak v Unixu.

Pro vytváření příkazových souborů však existuje ještě jedna motivace - zrychlení odezvy uživatele. Myšlenka předem si připravit příkazy a pak je zadat jako celek totiž nemusí nutně být vázána jen na operační systém a jeho příkazy. Stejně tak dobře je možné si předem připravit příkazy pro nějakou interaktivní aplikaci a pak zajistit, aby si je dokázala sama převzít z příslušného příkazového souboru. Aplikace pak nebude muset čekat na reakci uživatele, která je vzhledem k rychlosti aplikace (resp. počítače) vždy velmi pomalá a může dále pokračovat plným tempem.

Že vás nenapadá sitauce, kdy by se takovýto mechanismus mohl hodit? To jste se svým počítačem asi ještě nikdy nekomunikovali po telefonu (přes modem) s jiným počítačem (např. se stanicí BBS). Voláte-li meziměstsky či komunikujete-li s takovým systémem, kde platíte za délku spojení, je ve vašem vlastním zájmu, aby vše šlo co možná nejrychleji. Pak je velmi výhodné svěřit komunikaci s protější stranou příkazovému souboru, který za vás včas a maximální možnou rychlostí zadá např. vaše uživatelské jméno a heslo, vyžádá si došlou poštu apod.

Většina komunikačních programů pro osobní počítače je dnes vybavena často dosti složitým řídicím jazykem, který umožňuje sestavovat příkazové soubory k právě naznačenému účelu. Příslušným příkazovým souborům se v angličtině říká script files či pouze scripts (česky nejspíše skripty, podobně jako v Unixu) a jazyku pro jejich sestavování script language (skriptový jazyk). Příkazy tohoto jazyka umožňují mj. vysílat zadané řetězce znaků (které mohou představovat např. příkazy pro přihlášení do systému na druhé straně či jiné příkazy pro tento systém, dále jména, hesla apod.) a také čekat na předem určené řetězce znaků od druhé strany (aby bylo možné např. zachytit okamžik, kdy protější strana požaduje zadání uživatelského jména, a adekvátně na to reagovat).