Bash – Ctrl-c kills shell when pipeline is used in input redirection subshell

1. Yes. More precisely, in the shell, a pipe connects the standard output of the command on the left to the standard input of the command on the right. Even more precisely, what foo | bar means to the shell is:

   1. Create a pipe.
   2. Fork a child process, and connect the write end of the pipe to its standard output. Then execute foo in this child process.
   3. Fork a child process, and connect the read end of the pipe to its standard input. Then execute bar in this child process.
   4. Wait for both child processes to exit.

2. Yes. Ordinary redirections indicate a file by name: >foo. Another form of redirection indicates a file by descriptor. For example, >&2 means “redirect standard output to whatever file descriptor 2 is currently connected to”.

   On that topic, note that redirections are processed from left to right. For example, to redirect both standard output and standard error to the same file, use foo >filename 2>&1. The command foo 2>&1 >filename typed in a terminal would first connect standard error to the terminal (which both standard output and standard error are still connected to at that point, so it wouldn't make any difference), then connect standard output to the file.

3. Yes, but. The pipe construct in the shell creates an anonymous pipe; there are also named pipes.

   mkfifo f
   cat f
   # (in another terminal)
   echo hello >f
   

   Named pipes are a lot rarer than pipelines. They're used when it's necessary to connect two processes that are started independently; this doesn't happen very often, but it's nice to have it when necessary.

   Note that the replacement you gave: foo >tempfile; bar <tempfile is different: first foo writes all of its output to the temporary file, then bar starts running. With a pipeline, the commands run in parallel.

4. Yes, but it's not very useful.

   cat input_file | some_command   # a uselessly complicated way of writing some_command <input_file
   echo hello | tee output_file    # a uselessly complicated way of writing echo hello >output_file
   

It helps a bit if you think the file descriptors as variables that accept a file as a value (or call it an i/o stream) and the order they appear is the order of their evaluation.

What happens in the above example is:

1) The script starts (as per default and unless otherwise inherited) with the following

fd/0 = stdin    # that's the keyboard
fd/1 = stdout   # that's the screen
fd/2 = stderr   # the screen again, but different stream

2) The exec command translates to declaring a new variable and assigning a value

fd/3 = fd/1  # same as stdout

So now, two file descriptors have the value stdout, i.e. both can be used to print to the screen.

3) before ls is executed and inherits all open file descriptors, the following setup happens

ls.fd/1 = grep.fd/0    # pipe gets precedence, ls.fd/1 writes to grep.stdin
ls.fd/2 = ls.fd/1      # ls.fd/2 writes to grep.stdin 
ls.fd/1 = ls.fd/3      # ls.fd/1 writes to stdout
ls.fd/3 = closed       # fd/3 will not be inherited by `ls`

fd/3 has served the purpose of keeping the stdout value long enough to return it to fd/1. So now everything that ls sends to fd/1 goes to stdout and not grep's stdin.

The order is important, e.g. if we'd run ls -l >&3 2>&1 3>&-, ls.fd/2 would write to stdout instead of grep's stdin.

4) fd/3 for grep is closed and not inherited. It would be unused anyway. grep can only filter error messages from ls

The example provided in ABSG is probably not the most helpful and the comment "Close fd 3 for 'grep' (but not 'ls')" is a bit misleading. You can interpret it as: "for the ls, pass the value of ls.fd/3 to ls.fd/1 before unsetting so it won't get closed".