Re: when output of <( ... ) is stored in function argument, it can be used only once - why?

[Ante Bilandzic]

Thanks for all the feedback and detailed clarifications, now all it's
clear!

I was carried away by the fact that the other functionality, namely command
substitution $( ... ), can be used that way, for instance:

$ what(){ wc -l <<< $1; wc -l <<< $1; }; what "$(ls)"
18
18

Cheers,
Ante

On Tue, Jan 24, 2023 at 9:50 AM Kerin Millar <kfm@plushkava.net> wrote:

> On Tue, 24 Jan 2023 09:23:37 +0100
> Ante Bilandzic <abilandzic@gmail.com> wrote:
>
> > Hello,
> >
> > Please can somebody answer the question in the subject line, or point me
> to
> > relevant documentation where the underlying mechanism at work is
> explained?
> >
> > It is reduced to the bare bones with the following one-liner:
> >
> > $ what(){ wc -l $1; wc -l $1; }; what <(ls)
> > 18 /dev/fd/63
> > 0 /dev/fd/63
> >
> > In my particular case, 18 is the correct number of lines in the output of
> > <(ls). Why the 2nd and identical execution of 'wc -l' doesn't also get it
> > right?
>
> The sequence of events is approximately as follows.
>
> 1) Through process substitution, you set up a named pipe with ls as a
> writing process.
> 2) You pass the name of this pipe to the what function.
> 3) wc instance #1 reads the pipe, until it encounters EOF, indicating that
> there is nothing more to be read.
> 4) wc instance #2 reads the pipe, immediately encountering EOF (because ls
> has closed its end at this point).
> 5) wc instance #2, having read nothing, correctly reports 0 lines.
> 6) Finally, the reading end of the pipe is closed and the pipe is rendered
> defunct.
>
> Essentially, there is no way to make your example work as you expect. Were
> it a case of reading from a regular file, it would be possible to use a
> syscall such as fseek(3) to situate the file position indicator at the
> beginning of the file again, before reading it a second time in full.
> However, bash does not offer a usable abstraction for that particular
> syscall. Besides, it is impossible to seek for a file descriptor that
> refers to a pipe.
>
> --
> Kerin Millar
>