Különben a for ciklusos megoldásod nem tetszik, mert a teljes eredmény listát helyettesíteni kell. Amennyiben van erre felső memória limit, úgy belefuthatsz abba, hogy egyszer csak nem működik. Az lehet, hogy aki a bash-t írta, volt olyan jó fej, hogy nem szabott limitet, amíg a kernel ad RAM-ot, addig jó, de akárhogy nézzük, mindenképpen csak véges hosszúságú lista dolgozható így fel. Ráadásul kétszer foglalod le a memóriát ugyanazzal a listával: egyszer az EREDMENY változó által, másodjára a for-ba történő helyettesítéskor.
Ezzel szemben a pipe bármilyen hosszú listát feldolgoz, hiszen a lista előállítása és feldolgozása röptében történik, a pipe buffer mérete talán 4 kiB - aki jobban nyomonköveti a kernel fejlődését nálam, legfeljebb kijavít, ha már nem ennyi.
Ennek tehát az a következménye, hogy a feldolgozandó adatmennyiségtől függetlenül kevés memóriát allokálsz, így nem kell attól tartanod, hogy az Out of Memory Killer szépen kivágja a programodat, mert elfogyott a RAM. Persze előtte vergődik egy kicsit, mert a kernel jóságos, igyekszik menteni a helyzetet swap-eléssel, ettől legalább az egész gép nagyon lassú lesz.
Amikor a programot szervezed, erre is légy tekintettel. Egy eleve meghatározhatatlan adatmennyiséget, mint amilyen az fdupes kimenete, nem szerencsés változóban tárolni, aztán még egyszer helyettesíteni.
tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE