[QUESTION] Inheritance of file descriptors in <( ... ) construct

[QUESTION] Inheritance of file descriptors in <( ... ) construct

[dana]

Hello,

I'm wondering about the following behaviour:

  % ( fd=; exec {fd}>&2; : $( print foo >&$fd ) )
  foo
  % ( fd=; exec {fd}>&2; : =( print foo >&$fd ) )
  foo
  % ( fd=; exec {fd}>&2; : <( print foo >&$fd ) )
  zsh: 12: bad file descriptor

As you can see, $fd (12) was inherited by the $( ... ) and =( ... ) constructs,
but not by the <( ... ) one.

Everything works as expected with FDs < 10, though:

  % ( fd=9; exec 9>&2; : $( print foo >&$fd ) )
  foo
  % ( fd=9; exec 9>&2; : =( print foo >&$fd ) )
  foo
  % ( fd=9; exec 9>&2; : <( print foo >&$fd ) )
  foo

Is this intended and/or desirable? Maybe something to do with the fact that
<( ... ) is itself exposed as a >=10 file descriptor? But it seems smart enough
not to re-use the number that $fd had (it uses 13 in this example), so...?

Cheers

dana

Re: [QUESTION] Inheritance of file descriptors in <( ... ) construct

[Bart Schaefer]

On Fri, May 25, 2018 at 5:01 PM, dana <dana@dana.is> wrote:
>
> I'm wondering about the following behaviour:
>
>   % ( fd=; exec {fd}>&2; : $( print foo >&$fd ) )
>   foo
>   % ( fd=; exec {fd}>&2; : =( print foo >&$fd ) )
>   foo
>   % ( fd=; exec {fd}>&2; : <( print foo >&$fd ) )
>   zsh: 12: bad file descriptor

This looks similar to the thread around workers/42708 ... except that
instead of not closing the descriptor created by <(...) we also need
to not close FDT_EXTERNAL descriptors when spawning <(...).

There doesn't seem to be any straightforward way to do this with the
current implementation of closem().