Szerző: Bojcsuk Dóra

Hőtérképpel (heatmap) bizonyára már mindenki találkozott az internetes böngészése során, miközben egy időjárás-előrejelző oldalon rátekintett a Magyarország térképre és azt látta, ragyogó napsütésnek csupán a Balaton környékén van nyoma. Legtöbbször valóban a hőmérsékletet, csapadékmennyiséget jelző térképek esetében találkozhatunk ezzel a vizualizációs módszerrel, mely eltérő színek vagy színintenzitások használatával mindenki számára könnyen értelmezhető. Jócskán akad szerepe azonban a biológiában is, például génexpressziós vizsgálatok során.

Leggyakoribb a hideg-meleg érzést keltő zöld-piros, kék-piros vagy kék-sárga-piros, illetve ezen színek közötti átmenetek alkalmazása. Így például a nagyobb mértékben expresszálódó gének piros, az alacsony kifejeződést mutató gének pedig zöld négyzetként jelennek meg egy hőtérképeken. Az átmenetek értelmezéséhez azonban szükségünk van egy alsó-felső(-középső) értéket jelölő skálára is. Ebben a bejegyzésben azt fogom elmagyarázni, milyen módszerekkel tudjuk genomi régiók lefedettségét hőtérképen ábrázolni.

A genomi régiók lefedettségének megjelenítése kissé szofisztikáltabb a microarray vagy RNS szekvenálási módszerek által eredményezett génexpressziós értékek ábrázolásához képest. Utóbbi két módszer „jól meghatározott” értékeket szolgáltat, melyeket táblázatként kezelve akár a ClustVis weboldalon is pillanatok alatt ábrázolhatunk. A ClustVis bár számos R programcsomagot integrál (ggplot, pheatmap, RColorBrewer, stb.), egyetlen hátránya, hogy a megjeleníthető sorok száma maximalizálva van. Ezeket a programokat az ngsdeb szerverünkön keresztül az R programot meghívva is elérhetjük, aki pedig az R-hez készült fejlesztői környezetet, az RStudio-t használja, annak előbb telepítenie kell azokat. Mindhárom megközelítés a következő stílusú hőtérkép(ek)et eredményezné:

Mit jelentenek a sorok és az oszlopok?

Minden sor egy gént reprezentál, az oszlopok pedig az adott sorban lévő gén 4 különböző expressziós értékének megfelelő színintenzitást veszik fel. Ezen az ábrán az A1 és A2, illetve a B1 és B2  oszlopok együtt értelmezendők, mivel azonos kondíciót (A1 és A2: kezeletlen; B1 és B2: kezelt) ábrázolnak. Ahhoz, hogy ne egy pepita képet lássunk, lehetőségünk van hasonlóság alapján klaszterezni az értékeket. Többféle klaszterezési mód létezik (hierarchikus, korreláció-alapú, Euklideszi távolság, Pearson, Spearman, Kendall-féle tau, stb.); a jobb oldali hőtérkép egy hierarchikus klaszteranalízis eredményét ábrázolja.

No, de hogyan lehet genomi régiók lefedettségét ábrázolni?

Egy korábbi bejegyzésben már volt szó a HOMER programcsomagról és a HOMER tag directory-jairól. Ezeket a tag könyvtárakat, amelyek a genomra térképezhető leolvasásokat tartalmazzák, a ChIP-seq_anal.sh pipeline-unk az alapanalízis során minden mintára egységesen létrehozza.

A leolvasások általi lefedettség értékek arányosak az adott pozícióban megvalósuló fehérjekötés gyakoriságával és erősségével, így tehát alkalmasak arra, hogy két, vagy akár több tíz mintában összehasonlíthassuk adott régiók egy bizonyos, vagy több fehérje általi lefedettségét.

Ehhez a következő parancssort kell begépelnünk:

annotatePeaks.pl peaks.bed hg19 -size 2000 -hist 50 -ghist -fragLength 150 -d ../tag_directory_of_the_sample/ > output_table.txt

Mi mit jelent?

Az annotatePeaks.pl maga a parancs;

a peaks.bed fájl kell, hogy tartalmazza a régiókat, ahol a lefedettséget szeretnénk “megszámolni”;

a hg19 megadja a genomot (hg19: humán genom 19-es összállítása) és annak verzióját, de természetesen ez a fajtól és verziótól függően opcionális (hg18, mm9, mm10, stb.). Azt kell tudnunk, hogy a program ezen régiók határainak számtani közepét fogja középpontnak tekinteni, amely nem minden esetben jelenti a kötőhely valós csúcspontját. A nagymértékű eltolódások elkerülése végett legtöbbször a peak-ek summit pozícióját tartalmazó BED fájlt szoktuk megadni;

a -size 2000 paraméterrel pedig – jobb esetben – a summit pozíciókat egységesen kiterjesztjük -1000/+1000 bázispárnyi (bp-nyi) régióra. Így tehát összesen 2000 bp-nyi régión számolja a lefedettséget.

A -hist 50 megadja, hogy a 2000 bp-on belül hány bp lefedettségértékét átlagolja, azaz ebben az esetben 50 bp jelent egy ún. bin-t. Mivel a teljes régió 2000 bp lesz, mi pedig 50 bp-onként szeretnénk visszakapni egy értéket, azt jelenti, hogy a kimeneti fájlunkban 20+1+20 oszlop lesz (-1000 -950 -900 … 0 … +900 +950 +1000).

A -ghist kapcsoló régiónként kiszámolja a bin-ek lefedettségét;

a -fragLenght 150 paraméterrel az automatikus fragmenthossz számítása helyett azt tetszőlegesre állítom (opcionális). Megj.: A HOMER alapvetően a pozitív és negatív szálra térképeződő leolvasások egymáshoz viszonyított eloszlása alapján számolja ki az átlagos, elméleti fragmenthosszt.

Végezetül pedig a -d kapcsoló után kell megadnunk egy, vagy akár több minta HOMER tag könyvtárát.

A > karakter után a kimeneti fájl neve következik, melynek kiterjesztése .txt kell legyen, hogy a későbbiekben könnyen ábrázolni tudjuk..

Ábrázolás

A sok-sok sorból és oszlopból álló táblázatunkat ezek után már csak meg kell jelenítenünk. Ehhez mi a Java TreeView programot használjuk, ami bárki számára ingyen elérhető, letölthető a http://jtreeview.sourceforge.net/ weboldalról.

A program megnyitását követően tallózzuk be a táblázatunkat (File -> Open)! Automatikusan felajánlja, hogy az adott mappában csak a CDT vagy PCL kiterjesztésű fájlokat mutassa; itt ki kell válasszuk az All Files opciót. Innentől a táblázat megnyitása már csak annak méretén és a számítógépünkben található memória mennyiségétől függ. 🙂 Ha a betöltés leáll, próbáljuk meg egy jobb teljesítményű számítógépen ábrázolni, vagy osszuk két, vagy akár több részre a táblázatunkat!

Meg kell jegyezzem, hogy a TreeView-ban való megjelenítéshez a táblázat első két oszlopának egy-egy (megegyező) azonosítót kell tartalmaznia. Ez lehet akár a gének, a pozíciók neve, vagy akár egy sorszám. A táblázat első sorában is egy, az adott oszlopra vonatkozó azonosítónak kell szerepelnie. Ezek hiányában a táblázatban szereplő lefedettségértékek első két oszlopa és az első sora fogja ezt kiváltani, melyek emiatt nem lesznek ábrázolva.

Sikeres betöltést követően a következő kép fogad minket:

Ezt követően a Settings -> Pixel Settings-re kattintva egy új ablak jelenik meg, ahol mind a négy skála esetében a Fixed Scale-ről át kell klikkelnünk a Fill-re:

Szintén a Pixel Settings panelben tudjuk megváltoztatni az pozitív/negatív, a hiányzó és a nulla értéket felvevő bin-ek színét. Esetemben a “Positive”-at feketére, a “Zero”-t pedig fehérre változtatva, továbbá a skálát (Value) 3-ról 5-re átállítva a következő eredményt kaptam: 

Az 5-ös érték azt jelenti, hogy egy bin-ben ha a lefedettségérték eléri az 5-öt, fekete színként jelenik meg. A skála csökkentésével kontrasztosabb képet kapunk, mivel egyre több olyan bin lesz, amely eléri a beállított értéket.

Az ábrán megjelenített kötőhelyek előzetesen egy másik minta középső 50 bp-nyi régiójának lefedettsége alapján sorba lettek rendezve, ennek köszönhető ez a mintázat.

Az elkészült ábrát az Export -> Export to Image menün keresztül tudjuk letölteni. Azonban itt is figyelni kell néhány dologra:

Be tudjuk állítani az X- és az Y-tengely méretét, tehát az exportálni kívánt kép méretarányát. Amennyiben idő közben belekattintottunk a kirajzolódó képbe, a Selection Only-nál egy pipa jelenik meg – ezt ignorálnunk kell, ha az összes sort szeretnénk képként kinyerni. Végül pedig a bal oldalon kékkel kiemelt -1000 és Gene sorokra (amelyek esetemben az első sor és oszlop tartalmát jelzik) a Ctrl billentyű lenyomása mellett rá kell kattintani, hogy a kék kiemelés eltűnjön. Amennyiben ezt nem tesszük meg, a több tízezer soros táblázatunk minden sorának neve szerepelni fog az ábránkon. Természetesen néhány sor/oszlop megjelenítése esetén ez még akár jól is nézhet ki.

No, és mit rontottam el? Mivel -1000 van a név helyett, azt jelenti, hogy az első bin-emet elvesztettem az ábráról, mert nem duplikáltam meg az első oszlopot. 🙂

Utolsó lépésként mentsük el az ábránkat.

 
Az Emberi Erőforrások Minisztériuma ÚNKP-17-3-IV-DE-140 kódszámú Új Nemzeti Kiválóság Programjának támogatásával készült.

Szerző: Bojcsuk Dóra

Az alapanalízis során “készülnek” olyan fájlok, amelyek alkalmasak genom böngészőkben történő megjelenítésre. Ilyen például a BAM fájl, amely pontosan megmutatja, hogy egy adott minta esetében a genom mely szakaszaira és mennyi read (leolvasás) térképeződött, illetve jelzi a leolvasásokban azokat a nukleotidokat is, amelyek a referencia genomhoz képest eltérést mutatnak.

De megjelenítésre alkalmasak a különféle BEDGRAPH-ok is, melyek a genom teljes “hosszában” Gauss-i eloszlást mutató csúcsokat rajzolnak ki; ebben az esetben a csúcsok magassága és szélessége attól függ, adott pozícióra hány read térképeződött. Megjeleníthetjük ugyanakkor a BED fájlokat is, önmagukban vagy BEDGRAPH-okkal együtt; utóbbi abban az esetben lehet hasznos, ha szeretnénk látni, egy kívánt lókuszon mely csúcsok érték el azt a küszöbértéket, amely alapján a MACS2 vagy a HOMER programok őket a kötőhelyek csoportjába sorolta, vagy sem.

Talán az IGV (Integrative Genomics Viewer) a légszélesebb körben használt genom böngésző. Számos hasznos tulajdonsággal rendelkezik; az egyszerű ide-oda húzgálás vagy a vizsgálni kívánt genomi régió célzott megjelenítése mellett egy listát létrehozva egyszerre több régió is megjeleníthető, amely funkció különböző ábrák készítésekor nagyon hasznos szereppel bír. A betöltött track-ek, ún. mintasávok sorrendje, elnevezése, a sáv mérete vagy épp színe egy-két klikkeléssel könnyen megváltoztatható.

Honnan tölthető le az IGV?

A https://software.broadinstitute.org/software/igv/ weboldalon a Downloads panel alatti nyílra kattintva megjelenik egy újabb oldal, ahol  kiválaszthatjuk az általunk használt operációs rendszerrel kompatibilis verziót, ill. ha nem rendelkezünk Java-val, közvetlenül innen azt is letölthetjük – a Java ugyanis, mint kiegészítő modul (plug-in), elengedhetetlen a IGV futtatásához.

Letöltést és indítást követően egy “üres ablak” fogad bennünket; a fontosabb paneleket funkcióit az alábbi ábrán feliratozva találjátok:

Végezetül pedig nézzük meg, hogyan néznek ki a fent említett fájltípusok az IGV-ben:

Első mező (coverage): BEDGRAPH fájlt, ami a transzkripciós faktor kötőhelyeket (ún. peak-eket) mutatja.

Második mező (peaks): a kék négyzetek a BED fájl tartalmát jelenítik meg, azaz jelölik a peak-ek pontos kezdő- és végpozícióit. Jól mutatja, mely feldúsulások valódi kötőhelyek és melyek nem.

Harmadik mező (BAM): a BAM fájl tartalmát jeleníti meg, amely az adott genomi pozícióra térképeződött leolvasásokat mutatja.

Az Emberi Erőforrások Minisztériuma ÚNKP-17-3-IV-DE-140 kódszámú Új Nemzeti Kiválóság Programjának támogatásával készült.

Szerző: Bojcsuk Dóra

Az újgenerációs szekvenálás (NGS) lényege, hogy több tízmillió (vagy akár százmillió), viszonylag rövid (50-200 nukleotid hosszú) DNS szekvenciát határozunk meg véletlenszerűen, és utólag rakjuk össze, mi rajzolódik ki belőlük. Ennek megvalósítására a mai napig fejlesztenek módszereket, így nem meglepő, hogy nincs egységes „pipeline” (csővezeték) az elemzésekre.

A funkcionális genomikai módszereket három nagyobb csoportra oszthatjuk az elemzés szempontjából: mRNS szekvenálás esetén az intronok kivágódásának köszönhetően a leolvasott szekvenciák többsége az egymást követő exonokra – akár három-négy exonra is – esik, így csak az exon-intron határok felismerésével történhet meg a szekvenciák referencia genomra illesztése. A kromatin 3D szerkezetének megismerését célzó módszerek esetében a meghatározott DNS fragmentumok – ideális esetben – többnyire két távoli genomi régióra esnek, amely e régiók fizikai közelségét jelenti, és amely egy teljesen másfajta technikai megközelítést igényel. A legegyszerűbb eset, amely a funkcionális genomikai módszerek többségére érvényes, hogy a meghatározott DNS szakaszok egy az egyben illeszkednek a referencia genom bizonyos szakaszaira. Ilyen módszerek például a kromatin nyitottságát vizsgáló DNase-, FAIRE-, Sono- és ATAC-seq, a különböző fehérjék ellenanyagát felhasználó ChIP-seq és az újonnan képződött RNS molekulák feltérképezésére szolgáló GRO-seq is. Az e módszerek alkalmazása során kapott szekvenciák feldolgozása tehát hasonlóképpen hajtható végre, és a szekvencia-feldúsulások jellegének megfelelően csak a végső lépésekben szükséges különbséget tenni az eredmények között.

A ChIP-seq_anal pipeline-unk (Barta, EMBnet.journal, 2011) az előbbieknek megfelelően nemcsak a kromatin csúcsszerű és szélesebb fehérjefeldúsulásait képes feltérképezni, hanem bármely olyan módszer szekvenciáinak a feldolgozására is alkalmas, amely a genomhoz viszonyítva folytonos leolvasásokat eredményez. Egy további nagy előnye, hogy ha megadjuk az ftp elérést, az NCBI újgenerációs szekvencia adatbázisából (SRA, Sequence Read Archive) közvetlenül letölti helyettünk a szekvenciafájlokat.

A legnagyobb előnye talán a teljes automatizáltság: ha létrehozunk egy-egy könyvtárat az ideiglenes (pl. FQ/fastq) és a feldolgozott fájloknak (pl. analysis), és megadunk egy listát arról, hogy mit és milyen néven szeretnénk elemezni, már indíthatjuk is a programot, minták számának függvényében pedig néhány nap alatt meg is kapjuk az eredményeket.

Hogyan kell kinéznie tehát egy ilyen listafájlnak?

A vi szövegszerkesztőt megnyitva, majd szerkesztési módba lépve, a fenti séma szerint kell elkészítenünk a listafájlunkat (samples.lst). A szövegfájl első oszlopa minden esetben tartalmazza a minta nevét, ahol fontos, hogy a genomok megkülönböztetése érdekében a mintanevek elején ’mm_’ ill. ’hs_’ karakterekkel kell a fajt megadni. Abban az esetben, ha a minta SRA adatbázisból történő letöltésére az elemzés során kerül sor, a beírt név a leendő mintanevet jelöli, ha viszont a FASTQ fájl már a szerverünkön, a fájljaink között található, az elemzésre váró minta pontos nevét kell feltüntetnünk. A második oszlop hivatkozik a minták SRA adatbázisban lévő elérhetőségére, az utolsó oszlop pedig a minta jellegétől függően felveheti az ‘input‘, ‘factor‘, ‘histone‘ vagy ‘groseq‘ címkéket. Ennek jelentőségéről részletesebben néhány bekezdéssel alább olvashattok. Fontos, hogy az oszlopok tartalmát egy-egy tabulátor választja el.

Ha párhuzamosan több listafájlt használunk, a fent említett futási idő a töredékére csökkenhet. Saját, vagy már letöltött adatok esetén nyilván nincs szükség az ftp cím megadására, csak a mintanevekre és a típusokra (ez esetben a listafájlban az ftp elérést egy plusz tabulátor helyettesíti). Ehhez azonban a szekvenciafájlt (FASTQ) vagy szimbolikus linkjét létre kell hozni a megfelelő könyvtárban (FQ/fastq).

A FASTQ szekvenciafájlok szekvenciánként 4 – tehát összesen n*4 – sorból állnak (ahol n a szekvenciák száma): egy ’@’ karakterrel kezdődő azonosító sorból, magából a szekvenciából, egy mindenképp ’+’ karakterrel kezdődő, opcionális „leírás” sorból és a szekvencia bázisonkénti minőségi mutatóinak sorából állnak. Az SRA-ban e hatalmas szövegfájlok tömörített verzióját, az ún. sra-lite fájlokat tárolják, amely a fastq-dump nevű programmal alakítható vissza szekvenciafájllá – természetesen ez is be van építve a pipeline-ba. UNIX parancssorban az ilyen mértetű fájlokat általában gzip-pel tömörítjük, amely zcat paranccsal gyorsan kibontható (a memóriába). A szekvenciák mm10 vagy hg19 referencia genomra illesztését a BWA programmal végezzük, amely végső soron egy olyan szövegfájlt hoz létre, amely mind a szekvencia adatokat, mind pedig a genomi koordinátákat tartalmazza (sequence/alignment map azaz SAM formátum), tárolásra ennek a binárisan tömörített (BAM) változatát használjuk, amely a SAMtools csomaggal hozható létre és indexelhető az adatok könnyebb elérése (pl. megjelenítése) érdekében.

Eddig a pontig nagyjából bármilyen szekvenciafájllal ugyanaz történik (kivéve persze az mRNS vagy 3D kromatin adatokat, amelyeknél már az illesztés is eltér), ezután lesz jelentősége a minta jellegének, amit a listafájlban kell definiálni. ChIP-seq esetén pl. a transzkripciós faktorokra jellemző a csúcsszerű feldúsulás az általuk kötött szabályozó hely körül, míg a különbözőképpen módosított hiszton fehérjék zöme szélesebb régiót fed le, és a szabályozó helyek pont kimaradnak, mert ott a hisztonokat más fehérjék váltják fel.

A polimeráz fehérje döntően géneket fed le, bár ez esetben is elkülöníthetőek csúcsok és szélesebb feldúsulások – a csúcsok a promóterek és enhanszerek környékén, az egyenletes lefedettség a gének testén jellemző. A kromatin nyitottságára specifikus módszerek is csúcsokat adnak, tehát hasonlóképpen kezelhetőek a faktor ChIP-seq adatokhoz. Az előbbiek szerint a ’factor’ és ’histone’ címkékkel lehet ellátni a mintákat, és az elemzés ennek megfelelően fog tovább folytatódni.

Ezek mellett kontroll mintákat is meg lehet adni – a listafájl(ok) elején ’control’ címkével, pl. aspecifikus IgG antitest esetében, vagy input minta esetében, amelyeknél nem várunk semmilyen feldúsulást, így alkalmasak a különböző minták hátterének és feldúsulásainak elkülönítésére. A GRO-seq, jellegénél fogva külön ’groseq’ címkét kapott, mivel szálspecifikusan az átíródó gének és enhanszerek határozhatóak meg vele, melyek pontos körülhatárolása és elkülönítése egy teljesen más kihívást jelent.

A szekvencia feldúsulások meghatározására a HOMER és MACS2 programcsomagokat használjuk. Ezek alkalmasak azoknak a régióknak a megtalálására, ahol a háttér lefedettségénél jelentősen több leolvasás található; ezek a régiók BED fájl formájában tárolódnak és tartalmazzák a csúcsok vagy szélesebb régiók genomi koordinátáit, de a teljes genom „domborzatát” is végigböngészhetjük ugyanakkor a HOMER és a MACS2 által létrehozott lefedettség (BEDGRAPH) fájlok segítségével. A HOMER alkalmas továbbá kiválasztott genomi régiók lefedettségének a kigyűjtésére – hisztogram vagy hőtérkép formájában –, valamint a csúcsok alatti szekvenciák feldúsulásainak a meghatározására és az így talált szekvenciamotívumok visszatérképezésére, nem mellesleg egyéb annotálási feladatok elvégzésére is…

…ezekről részleteiben viszont a további bejegyzésekben lesz szó.

Végezetül: milyen könyvtárakat kell definiálnunk a ChIP-seq pipeline indításakor és milyen sorrendben?

nohup sh <ChIP-seq_anal-v1_9mm10_fast.sh> <ChIP-seq/lists/samples.lst> <ChIP-seq/FQ/fastq> > <ChIP-seq/logs/samples.log> 2> <ChIP-seq/logs/samples.err> &

nohup: azért szükséges, hogy az elemzés a terminál bezárását követően is folytatódjon;

sh: parancs, amely jelzi, hogy egy shell szkriptet szeretnénk futtatni;

ChIP-seq_anal-v1_9mm10_fast.sh: ez maga a pipeline;

ChIP-seq/lists/samples.lst: a fent részletesen taglalt listafájl és elérési útja;

ChIP-seq/FQ/fastq: azt a mappát jelöli, amelyben a FASTQ fájlok megtalálhatóak, vagy ahová az SRA adatbázisból letöltést követően kerülni fognak;

a > jelöli a kimeneti fájlt, ebben az esetben egy log fájlt, amelynek kiterjesztése .log;

a 2> szintén egy kimeneti fájlt jelöl, viszont minden esetben hibafájlt, melynek kiterjesztése .err;

az & jellel a háttérbe küldjük a feladatot, így az éppen futó programok nem írják ki a képernyőnkre az aktuálisan futó vagy épp befejezett lépések automatikus üzeneteit, hanem azokat a *.log és/vagy *.err fájlokba gyűjti össze.

A fenti parancssort érdemes a ChIP-seq/analysis mappában indítani, így a pipeline a kimenetet az aktuális, analysis mappában fogja létrehozni.

 Az Emberi Erőforrások Minisztériuma ÚNKP-17-3-IV-DE-140 kódszámú Új Nemzeti Kiválóság Programjának támogatásával készült.

Szerző: Bojcsuk Dóra

A „W” billentyű nem csupán egy betűt rejt, hanem egy másik, elég fontos karaktert is – ha az AltGr-rel együtt használjuk; a „|” („pipe” vagy „cső”) karakter ugyanis egy olyan, a UNIX-alapú operációs rendszerek egyik hasznos funkciójával rendelkezik, amely egyben rámutat e rendszerek kizárólagos előnyeire. A cső karakter egy parancs kimenetét egy újabb parancs bemenetévé alakítja, függetlenül attól, mekkora szövegtömbről is van szó (a UNIX rendszerekben nincs memóriakorlát, annyi memóriát használhatunk, amennyi csak van a számítógépünkben). Ezáltal egészen hosszú láncok, ún. „pipeline”-ok vagy „csővezetékek” építhetőek fel parancssorban, az adott feladatsornak megfelelően, és elkerülve a nagyszámú ideiglenes fájl létrehozását.

Ez jelenthet egészen egyszerű lépéseket is, pl. ha egy tömörített vagy átdolgozott szövegfájl első vagy utolsó sorait szeretnénk ellenőrizni, pl. zcat fajl.gz | head vagy sed ’s/ /\t/g’ fajl.txt | tail. Az előbbi példa egy kicsomagolt szövegfájl első 10 sorának parancssorban való megjelenítésére alkalmas, az utóbbi példa pedig egy szövegfájl „space” karaktereinek tabulátorokra való cseréje után az utolsó 10 sor megjelenítésére. Ezen a módon meglehetősen összetett dolgokat is ki lehet hozni az adatfájlokból: nemcsak karakterek cseréjére vagy bizonyos sorok kigyűjtésére alkalmas a parancsok egymás után fűzése, hanem gyakorlatilag bármilyen adattranszformáció vagy számítás megoldható ezen a módon. A csővezetékek (ill. a UNIX) további előnye, hogy az extrém nagy fájlokat is ugyanolyan hatékonyan kezelik, mint a kisebb fájlokat, és ciklus(ok)ba foglalva akár extrém sok azonos típusú fájlon is végrehajtható ugyanaz a feladat.

Emellett persze még ott van a párhuzamosítás lehetősége is, ha a fájlok csoportjait definiálva indítunk el párhuzamosan ciklusokat, amellyel megsokszorozhatjuk a feladat megoldásának sebességét, és tovább csökkenthetjük a várakozási és gépelési időt. Ha nemcsak bizonyos feltételeknek megfelelően strukturált fájlokat, hanem egységes fájlneveket és fájlrendszereket is használunk, tovább nő az automatizálhatóság lehetősége, amellyel nemcsak a gépelés mennyiségét, így pl. a gépelési hibákat küszöbölhetjük ki, hanem a munkaidőt tekintve is sokkal hatékonyabbak lehetünk. A parancsvégi „&” karakterrel háttérbe küldve a feladatokat új paramétereket tesztelhetünk, vagy új feladatokba is belekezdhetünk – nem lesz szükség a folyamatok felügyeletére, csak a végeredményt, a végső fájlokat kell ellenőriznünk.

Létezik ezen felül egy „nohup” (no hangup) parancs is, amelyet a csővezetékünk elé írva az internetkapcsolat bontásakor sem áll majd le a feladat; bár ez ciklusok esetében csak akkor alkalmazható, ha azokat Shell szkriptekbe építjük.

Így vagy úgy, de egy nagyon hasznos parancsról van szó, amely megengedi, hogy a szerver tovább dolgozzon akkor is, ha már nem vagyunk jelen. Ez különösen akkor fontos, ha napokig-hetekig fut valami, és nem rendelkezünk feladatütemezővel. Ami már egy másik történet…

Az Emberi Erőforrások Minisztériuma ÚNKP-17-3-IV-DE-140 kódszámú Új Nemzeti Kiválóság Programjának támogatásával készült.