Capturing file descriptor 3, or alternatives.

[Joshua Judson Rosen]

Two thoughts:

    * Use Bash's `process substitution' syntax: "<(...)" and/or ">(...)"
      to pass the auxiliary process' stdin and/or stdout fd as an argument.
      If you don't want to have two script-files rather than one, then
      you may have to do something like...:

          bash -c 'while read pipe_in < $1
                   do
                       read -p "input for $pipe_in: " user_in
                       echo $pipe_in:$user_in
                   done' -- <(ls)

      (there may be a prettier way of doing that--not sure what it'd be,
       of the top of my head)

    * Do something with djb's `multitee' command.

Bill Freeman <ke1g.nh at gmail.com> writes:
>
> 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
> _______________________________________________
> gnhlug-discuss mailing list
> gnhlug-discuss at mail.gnhlug.org
> http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/
>

-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."