SOLVED: Capturing file descriptor 3, or alternatives.

[Ben Scott]

On Mon, Jun 25, 2012 at 11:09 PM, Ben Scott <dragonhawk at gmail.com> wrote:
>> What occurred to me is to send the final result to fd 3, which the
>> shell would have to have opened before forking. ...
>
> http://pastebin.com/RGBuRw0e

P.S.:

CAVEAT

  I should prolly make it explicit that I don't understand everything
about how/why the above works.  Specifically, I couldn't get it to
work without using the Bash exec builtin to change the shell's own
idea of stdout.  I'm pretty sure I understand the rest of it.  But
since my understanding is incomplete, that code may be doing something
really stupid that happens to work anyway.

WHY I BOTHER

  I learned some new things.

  I learned how to swap stdout/stdin around in the shell, and how to
use that with dialog.

  I learned that you can have the shell open new file descriptors,
obtaining the fd numbers as a variable, using syntax like
{varname}>foo (where "foo" is a file, or an fd to dupe with the &
syntax).

  I learned that you can "redirect" the shell's own std{in,out,err} by
calling the exec builtin with redirection, but no command specified.

REFERENCES

  In the process of coming up with this, I referenced the following
sections of the GNU Bash manual:

http://www.gnu.org/software/bash/manual/bashref.html#Redirections

"Each redirection that may be preceded by a file descriptor number may
instead be preceded by a word of the form {varname}. In this case, for
each redirection operator ... the shell will allocate a file
descriptor greater than 10 and assign it to {varname}."

http://www.gnu.org/software/bash/manual/bashref.html#index-exec-113

"If no command is specified, redirections may be used to affect the
current shell environment."

  Plus a variety of Google results that, while they didn't really
apply, gave me new ideas.

-- Ben