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

[alex xmb ratchev]

On Tue, Jan 24, 2023, 9:24 AM 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?
>

i d say , cause the lines been readen already
see cat file | { cat ; cat ; }
the second cat may hand reading stdin cause the previous cat already did
read

if u wanna reuse , u gotta data structure / vars , then act on those

the dev fd *63* is the fd created for that cmd

Use case: I am supplying to function through the first argument list of
> files generated via <(find ...), and then want to concatenate that list to
> the already existing list of files in some physical file with 'cat', but
> only if the output of <(find ...) is not empty. Therefore, I use 'wc' and
> 'cat' in the function body one after another on $1. Counterintuitively,
> 'wc' tells that $1 is not an empty file, while in the very next line 'cat'
> sees $1 as an empty file.
>
> Thanks!
>
> Cheers,
> Ante
>