SOLVED: Capturing file descriptor 3, or alternatives.

[Ben Scott]

P.P.P.S.:

On Tue, Jun 26, 2012 at 7:36 AM, Ben Scott <dragonhawk at gmail.com> wrote:
> http://pastebin.com/XdxWjpeU

  Ah-ha!  I think I just figured out why I need the exec builtin.

  I kept trying this one-liner:

ANSWER=$( ( dialog --output-fd 3 --inputbox 'Speak Friend and enter' 0
0  > /dev/fd/4 ) 3>&1 4>&1 )

  Thinking, "I'll dupe fd1 on to fd3, *and* fd4, and then specify what
I want to be stdout for dialog inside the subshell".

  The problem is, one can't change stdout for external commands.
stdout is fd1.  That's part of the 'nix specification.

  So when employing the output redirection operator for dialog, what
the shell does is *close fd1*, and then reopen it against the file
specified.  When fd1 is closed, I'm guessing it screws something up,
since dup'ed fd's share file offsets and the like.  (Although I'm
still guessing here.)

  I'm likewise guessing that when I call the exec builtin with no
command but with redirection, that actually changes what file
descriptor the shell considers to be standard input.  Instead of
reading fd0, it now reads fd3.

  That lets us close fd1 and open/dup fd4 to fd1 for the dialog(1)
process.  That process also inherits fd3 from the shell, and writes to
it.  The shell reads fd3 as input for the command substitution.

  Of course, I could be completely wrong...

-- Ben