Na de látod, nem tudsz mindent szabadon összeválogatni most sem, tudnod kell, hogy közéjuk kell iktatni ezt a konvertert, másként nem tudod őket összekötni.
Amit sokan elfelejtenek: a text sem univerzális interfész, annak is formátuma (kódolása, sorvégjele stb.) van, a két oldalnak meg ugyanazt kell beszélnie, ha meg akarják érteni egymást. És ehhez ugyanúgy tudnod kell, hogy az egyik program mit köp ki magából, a másik meg mit fogad el, hogy tudd, össze lehet-e kötni őket közvetlenül, vagy kellenek a konvertáló lépések a láncban.
A pipe-ban meg csak bytestreamek mennek, semmi más.
Most is pontosan ott vagyunk, amire azt mondod, hogy problémás:
Az interface definiálással pont az a probléma, hogy az egyik program ilyen interface-t csinál, a másik olyat, máris elérkeztünk egy olyan helyzethez, hogy lesz húszféle interface, mindegyik más, aztán az egyik program az egyikkel tud dolgozni, a másik a másikkal (majdnem).
Ez most is pontosan így van.
Edit: még egy dolog, ami nincs megoldva igazán jól a pipe-okban: a backpressure. Ha a fogadó oldal mondjuk másodpercenként olvassa a bemenetet, és csak 64kb-ot olvas belőle, cserébe a küldő oldal meg tizedmásodpercenként 2 MB-nyi outputot állít elő, akkor a shell fog pufferelni, amíg meg nem telik a memória.
Persze a pufferelésnek a másik oldalon is van problémája: ha a küldő oldal folyamatosan küld kevés adatot, de közte van egy puffer, akkor a fogadó oldal ritkán kapja meg az adatot, csak akkor, amikor betelt a puffer.
Persze erre ott van a https://www.gnu.org/software/coreutils/manual/html_node/stdbuf-invocati…, de ez is félmegoldás.
Miközben lehetne ezt sokkal okosabban is csinálni, csak ahhoz kétirányú csatorna kell a két processz között.