Je voulais pouvoir fournir un flux d'informations d'un script shell (bash) à quiconque voudrait le recevoir et jouer avec.
Forcément, on pense à un fifo en premier, mais les write sont bloquants. A priori pas simple le O_NONBLOCK en bash.
Ensuite on pense à des socket UNIX, sauf que c'est celui qui écoute qui la crée, et on ne peut pas écouter à plusieurs.
Ce thread fait un peu le tour. Une proposition parle de détourner UDP pour ça, car en mode datagram les paquets sont envoyés sans connexion, donc peuvent être perdus.
Avec socat c'est très facile (udp-datagram / udp-recv). Et l'envoi n'est effectivement pas bloquant. Par contre si on écoute à plusieurs sur le port, en mode reuseport, on n'a pas de duplication mais un balancing. La duplication s'effectue en mode broadcast (possible sur 127.255.255.255 par exemple).

socat udp-recv:3333,reuseport -
socat - udp-datagram:127.255.255.255:3333,broadcast <<< coucou

Ici une explication que j'ai trouvée a posteriori après avoir galéré facile une heure : pourquoi grep semble ne pas fonctionner quand il grep sur quelque chose qui ne termine pas, et dans une autre commande ? Par exemple :
while true; do echo a; sleep 1; done | grep '' | cat
=> rien
while true; do echo a; sleep 1; done | grep ''
=> fonctionne
Dans mon cas c'était inotifywait, grep, while read mais c'est bien pareil.
La réponse est toute bête mais il fallait y penser (ou lire tout le man de grep, merci ban :)) : buffer sur stdout. grep se fait bufferiser sa sortie, ce qui est tout à fait normal. Il suffirait d'attendre plein d'événements dans le pipe pour les voir arriver. Et le fait d'avoir un terminal au bout masque ça car il bufferise pas plus qu'un ligne.
Bref, il suffit de dire "--line-buffered" à grep :)