Re: redirection / process substitution fails to read a file descriptor

[Mike Peters]

On 2024-11-16 20:35, Greg Wooledge wrote:
> On Sat, Nov 16, 2024 at 16:35:05 -0600, Mike Peters wrote:
> > Description:
> >          Process substitution does not generate properly when pulling from another file 
> > descriptor, although it works when pulling from a file directly. In the below sample shell 
> > session, it is expected that `<(<test.txt)` would be functionally equivalent to 
> > `<(<&3)`.
>
> > Repeat-By:
> >          > echo foobar > test.txt
> >          > echo `< <(<test.txt)`
> >          foobar
>
> This is one of the most convoluted things I've seen in a long time.

Evidently I overlooked a further simplification I could have made for this 
example when converting the commands I was playing around with to test what 
works and what doesn't. *

> >          > exec 3<test.txt
> >          > cat <&3
> >          foobar
>
> OK.  This part is straightforward.  Note that you used a command, cat,
> to write output.  You didn't simply type <&3 without a command.

You're saying that <&3 on an input line by itself should work? It outputs nothing 
for me. Effectively the same point as the purpose of this submission. Although 
<test.txt by itself doesn't output anything for me either.

The purpose of this second part of the example was merely to show that reading from 
test.txt via an established good way via a FD does indeed print foobar, before my attempt 
in the third part of the example to show the counter "broken" behavior.

> >          > exec 3<test.txt
> >          > echo `< <(<&3)`
> >
> >          >
>
> I'm guessing that the parser sees the <& and decides *not* to treat
> this as a shortcut of cat with &3 as a filename.  Therefore, the only
> thing the parser can do is treat this as an empty command with a <&3
> redirection attached to it.

This is the clarification I needed, in which I was under a mistaken impression 
of the cat shortcut working also for file descriptors. Thank you.

----

* FWIW, this is what I was developing when I came upon the issue:

exec 3>&1 # save the monitor
exec 4>all.txt # generate single entry point for output
# otherwise output may not be in order
exec 1> >(tee out.txt /dev/fd/4 >&3) # out everywhere
exec 2> >(tee err.txt /dev/fd/4 >&3) # err everywhere
echo "session output..."
echo "session problems..." >&2
exec 6>&1 1>&3 6>&- # restore stdout
exec 6>&2 1>&3 6>&- # restore stderr
exec 4>&- # close all.txt


Mike Peters