Quote:
Originally Posted by catkin
Thanks  I think I've got it now. Is this correct:
The exec 4> > (<commands>) only defines fd 4; it is not instantiated until fd 4 is used by the echo <string> >4 when the subshell is created with its stdin already loaded. |
Depends on the implementation of the shell but I think it's most likely that before a data is sent to a FD, or before 'echo', everything is already set and fd 4 is already instantiated. That's what I think since it would probably be inconsistent if the shell acts differently. What's the use of a closer statement (exec n>&-) in that case?
Note that a pipe still works even though a data is not sent.
Code:
: | bash '{ echo a; read; echo $REPLY; }'
.. i think will still print 'a'
Sorry if my explanation is a bit cloudy.
edit: remember that after >(command) expands to a path, the subprocess that was created there just waits to another process to use its pipe. We can therefore conclude here that >(command) and exec in 'exec 4> >(command)' is not directly dependent to each other.
try to save the expanded value of >(command) to a variable and see if it works:
Code:
PIPEFILE=>(command)
echo pipefile is $PIPEFILE
exec 4> $PIPEFILE
: do something
exec 4>&-
if PIPEFILE=>(command) does not expand as expected try to use eval
Code:
eval PIPEFILE=>(command)
