I was reading this question on rpi and noticed an interesting line that got me thinking:mkfifo tcp.streamnc -l -p 1234 > tcp.stream | omxplayer --live tcp.streamNotice the io redirection. STDOUT is redirected twice! My concern is that omxplayer not having STDIN associated with anything usable might be a little hard to control, but I think this does have the advantage of killing nc with SIGPIPE when omxplayer exits. Is this a good idea? Is this something worth recommending in some odd cases?
using pipe to run command in background
shell;io redirection
The pipe will immediately get closed on nc's end.  When omxplayer dies nc will receive SIGPIPE on writing to the fifo, not to the pipe.It might be better to just run nc in the background so that you could keep control over omxplayer via stdin.mkfifo tcp.streamnc -l -p 1234 > tcp.stream &omxplayer --live tcp.streamHowever, using | instead of & actually makes sense in the view of shell's job control.Using |:$ mkfifo fifo$ nc -l -p 1234 >fifo | cat fifonc and cat belong to the same process group (PGID 9177).$ ps f -o pid,ppid,pgid,command  PID  PPID  PGID COMMAND 9095  1681  9095 bash 9179  9095  9179  \_ ps f -o pid,ppid,pgid,command 1691  1681  1691 bash 9177  1691  9177  \_ nc -l -p 1234 9178  1691  9177  \_ cat fifoBoth of them receive SIGINT then quit when user types Ctrl+C.Using &:$ mkfifo fifo$ nc -l -p 1234 >fifo & cat fifo[1] 9183nc and cat belong to different process groups (PGID 9183 and 9184).$ ps f -o pid,ppid,pgid,command  PID  PPID  PGID COMMAND 9095  1681  9095 bash 9185  9095  9185  \_ ps f -o pid,ppid,pgid,command 1691  1681  1691 bash 9183  1691  9183  \_ nc -l -p 1234 9184  1691  9184  \_ cat fifoIn this case, only foreground process (cat) receives SIGINT when user types Ctrl+C.  If nc doesn't yet get connected, it remains running in the background.^C$ jobs[1]+  Running                 nc -l -p 1234 > fifo &$ kill %[1]+  Terminated              nc -l -p 1234 > fifo