On 9 Jun 2000, Akim Demaille wrote:
> Steven> It would be nice to have a better understanding of the
> Steven> exec/eval interaction that caused the bug before, however,
> Steven> even though my patch removes that business entirely.
>
> Agreed. Maybe one cannot understand without having a strong
> experience in Unix programming :(
I've been thinking about it a little more, and I think I understand it.
The basic problem is with:
exec 5>&1
foo=`eval "echo bar >&5"`
This outputs "bar" to stdout, not to foo. The reason is that essentially
the following series of operations occurred:
1) fd 5 = fd 1 = stdout
2) The ` causes fd 1 = ->$foo. This does not affect fd 5, however, which
still points to stdout.
3) ">&5" is evaluated. This sets fd 1 = fd 5 = stdout.
4) "echo bar" sends its fd 1 output to stdout.
The basic problem is that exec 5>&1 does not make fd 5 an alias for fd 1,
it just makes their contents equal. So when fd 1 is subsequently
reassigned this doesn't affect fd 5.
My solution, on the other hand, was essentially (leaving out stderr):
foo=`eval "echo bar >&5" 5>&1`
1) The ` causes fd 1 = ->$foo.
2) For the eval command, the shell first sets up the redirections: fd 5 =
fd 1 = ->$foo.
3) Then the eval command executes, and it sets fd 1 = fd 5 = ->$foo before
evaluating "echo bar", which in turn sends its fd 1 (stdout) output
therefore to ->$foo.
The key thing is that the 5>&1 is executed *after* fd 1 has been
reassigned by the `...`.
Steven
