Capturing file descriptor 3, or alternatives.

[Bill Freeman]

I really hate string processing in bash.  So I'd like to write a
script in another language that 1. interacts with the user; 2.
calculates the desired values of some environment variables; and 3.
communicates those settings to the shell from which it was invoked
(since the environment variables are for other programs to be started
by that shell in the future).

I can't just use back-tick and print the information because I need
standard out so that I can print a menu and other prompts to the user.
 (I suppose that I could use stderr to talk to the user, but that
feels nasty.)

What occurred to me is to send the final result to fd 3, which the
shell would have to have opened before forking.  So, this works:

    $ script 3> some_file_name
    $ source some_file_name    # assume the output is an "export" command line
    $ rm some_file_name

This does have to be gussied up to use mktemp or tempfile, since it
could be being invoked on the same account simultaneously from other
terminals (the whole reason for wanting to use environment variables,
rather than "git config user.name" in the first place).

But I'd really like to get away from the separate file altogether and
get bash(sh) to build a pipe (unnamed)  to the child process's fd 3,
and either exec that (when it comes) or stuff it in a shell variable
(which I can then exec), all without redirecting stdin, stdout, or
stderr for the child.  (I got excited about the -u option to read, but
that's referring to the shell's fd 3, not the child's.)

Any thoughts?

Bill