( bucko | 2024. 07. 12., p – 00:16 )

Sajnos Nyosigomboc szinte szóról szóra leírta amit én is írtam volna.

Másrészről a cat nem más, mint egy mindenáteresztő filter és nem az ördögtől való. Alkalmazása nem erőforrászabáló, jómagam is alkalmazom akár bomyolultabb pipeline közepében is, akár nagymennyiségű adat feldolgozása közben. Ezek olyan esetek, amikor oda kell tenni valamit, ami csak átereszti a bájtokat. Alkalmazása nem különb. mint a pipe használata. És pont ez a szép a unix filozófiájában, hogy már mindent  megírtak csak össze kell kapcsolni a kész programokat. A mindent megírtak alatt nem szeretném azt állítani, hogy pozitívnak tartom a GNU awk fícsöreit, miszerint vérpistike belerakta a csillagászati számításokra és a mélytengeri merülésre is optimalizált kiegészítéseket.

"cat valami | tr", hanem az, hogy "tr < valami"

Na, pont erről beszélek! De ez az okoskodás legfeljebb a parancsok kézi próbálgatására jó. A való világban általában van egy "előző program", tehát a harmadik alak a tipikus: "valami  | tr".

Nem állítottam, hogy korábban (legyen a határ '90) mem léteztek többprocesszoros számítógépek vagy többprocesszoros UNIX rendszerek. Viszont a numproc  paraméter (core count vagy virtual processor count) nem igazán létezhetett és nem volt értelmezhető akkoriban. Ennek egy nagyon egyszerű oka van: a hardver. Akkoriban nem létezett multicore arch, de egy 8086 bus arbiter sem pont úgy működött, mint egy 860 vonalas fabric bus. Sőt még az IBM is készített egy tanulmányt, hogy 8 CPU felett az SMP nem gazdaságos. Nem sokkal később 32 CPU összeragasztásával nyerték sorra az adatbázisversenyeket. ;) Bár voltak igazán multiprocesszoros gépek amiken biztosan elfutkározott volna még a linux is - már ha létezett volna. Vagyis akkoriban abszolút nem volt tipikus egy többprocesszoros UNIX gép, de ha létezett is, a numproc értelmezése a mai hardverek alapján igen nehéz lett volna.