The urgent issue to read keyboard input in the pipeline is solved by the answer in https://stackoverflow.com/questions/15230289/read-keyboard-input-within-a-pipelined-read-loop:
mycommand-outputpiped | while read line do # do stuff read confirm < /dev/tty done Why does it work? Aren't tty redirected to standard input? Can I get a file descriptor of /dev/tty and use read -u fd instead? TIA
This works because /dev/tty is the controlling terminal, if any, and by redirecting from it you’re ensuring read reads from it rather than whatever standard input was before the redirection. If you didn’t do that, read would read from mycommand-outputpiped’s output.
A program’s standard input is, initially, whatever its parent process decides it should be. When starting a process from a shell in a terminal, without redirection, that will be the shell‘s controlling terminal; but any redirection of standard input replaces that.
By redirecting standard input from /dev/tty you are getting a file descriptor for it, 0; but since read reads from that by default, -u isn’t useful. There’s no other file descriptor guaranteed to point to /dev/tty. In many shells you could explicitly open a different file descriptor, but in this scenario there’s not much reason to do so.
