Nagyon sok sebből vérzik amit csinálsz.
Az első gyanús jel, hogy azt írod, "jött egy hibaüzenet", de be nem idéznéd nekünk. Ilyet nem csinálunk. Úgy kérdezünk, hogy megmutatjuk, mit csináltunk, és milyen váratlan eredményt kaptunk (nem körülbelül, hanem pontosan).
Nade nézzük a szkriptet.
A parallel (már ha a moreutils-féléről beszélünk, ami nekem az Ubuntuban van; nem tudom van-e másmilyen vele inkompatibilis) nem a stdin-jéről olvas, hanem az argumentumait dolgozza fel. Tehát semmi értelme pipe-olni a find-ból, és mivel nem kap fájlnév argumentumot, nem tudja hogy mit csináljon mivel. Talán egy xargs maradt ki?
A doksija szerint a {} jelet csak akkor értelmezi speciálisan, ha adsz neki -i kapcsolót, de nem adsz.
A manpage példáiban is látott módon nem adhatsz neki mini shell szriptet paraméterként, hanem vagy egy bináris nevét és paramétereit adod át külön paraméterekként, vagy sh -c bevezetéssel lehet egy mini inline shell szkriptet.
A doksija a {} használatát nem részletezi, de a find doksija igen. Ide simán behelyettesítődik a fájlnév, nem kap semmiféle escape-elést ami majd megvédené őt egy shell script parserétől és az lehámozná róla. Sajna ilyet nem lehet. Talán érdemes külső shell szkriptet írni segítségül, aki fájlneveket kap (mindegyiket egy külön paraméterben) és arra futtatja le a kívánt bonyolult kódot.
(Apró szőrszálhasogatás: azt vágod hogy a kódodban az első "{}" nem megvédi (idézőjelek közé teszi), hanem épphogy kiveszi ebből a kontextusból? A {} előtt bezársz egy zárójelpárt, utána újranyitsz egyet.)
De lépjünk vissza egy lépést. Mi a cél?
Az identify programnak megadhatsz több fájlnevet is. Meg biztos olyan formátumot is, hogy írja ki a kívánt választ (orientation-t) meg a fájlnevet is egy sorba. Egyetlen identify parancsnak betolsz csomó fájlnevet, aztán grepelsz a kívánt orientation-re. Csak akkor kell több parancs, egymás után, ha az argumentumlista túl nagy lenne. Erre a standard megoldás a find | xargs. Igaz, ez egy szálon (egy CPU-n) fog futni.
Ehelyett bedobod a parallel-t a képbe, tehát megdolgoztatod mindegyik processzort, de cserébe minden identify progi egyetlen fájlnevet kap(na elvileg az elképzelésed szerint), vagyis mindegyik fájlra kell a rendszerrek forkolnia és execelnie. Lenne egy fogadásom hogy amit a párhuzamosítással nyersz, azt ezzel sokszorosan elveszíted.
Persze a legjobb lenne a két módszer előnyeit ötvözni, lám, az xargs-nak van erre kapcsolója, nincs szükség olyan "fantasztikusan ügyes" külső progira, ami párhuzamosan ugyan, de egyszerre mindig csak egy fájllal hajtja végre a progit. Nyilván ennek is megvan a maga létjogosultsága, de ez most nem az.
Építkezz apró blokkokként. Egy ekkora nagy izé bonyolult parancssor nem működik. Nem egy hiba van benne, hanem sok, nemcsak szintaktikai hanem koncepcionális is. Szedd részekre. Működik a find önmagában? Gondolom igen, oké. Működik a parallel? Teszteld úgy, hogy kívülről is a find helyett egy fix bemenetet adsz (első körben egyszerű fájlnevet), meg belül is a bonyolult identify-os szkript helyett egy tök egyszerű echo-t. Ha megy, akkor lehet egyesével bonyolítani a komponenseket, illetve kipróbálni trükkös fájlnevekkel is.
Gondold végig, mi a cél, mennyi energiát érdemes belefektetni. Ha egyszer fog lefutni a gépeden, és az a kérdés hogy 10 mp vagy 10 perc alatt, érdemes-e sok-sok munkát belefeccölni és fórumozók segítségnyújtását kérni az optimalizáláshoz, érdemes-e bármiféle párhuzamosítást belerakni?