Re: anonymous pipes in recursive function calls

[Zachary Santer]

On Sat, Jun 29, 2024 at 2:29 PM konsolebox <konsolebox@gmail.com> wrote:
>
> On Sat, Jun 29, 2024 at 10:23 PM Zachary Santer <zsanter@gmail.com> wrote:
> >
> > The intention here is to report as many error conditions as possible
> > before exiting.
>
> You can print an error message before calling return.  Are you
> planning to run more commands even if an error has already happened?

"Error conditions" in the sense of things that would cause problems
later - minimizing the likelihood that something will only come up
after the script has already made some updates. If the script reports
multiple issues before any updates are made, the user can go and
resolve all that stuff before trying to run the script again. If the
script were to leave the user in a partially-updated state, the user's
left having to do the rest of the work manually.

> > Filling an array of paths and then looping over it in a subsequent for
> > loop wouldn't actually be unreasonable here, considering how many
> > paths there are. It just feels like bad practice.
>
> Why do you think it's a bad practice?

Some of the power of bash is the ease with which it enables
parallelism. Collecting all the output from a command or block of code
before it gets passed to the next is throwing away that benefit.
Additionally, you might find yourself with so much output that it's
too much to expand all at once in the for loop. Don't know what that
limit is, but you're at the very least using more memory than you
would be otherwise.

> > There's always the
> > possibility of busting out the named pipes again. Bash 4.2 couldn't
> > wait for process substitutions.
>
> The solution I suggested doesn't use process substitution so I'm not
> sure what you mean.

In my earlier email, I mentioned potentially trying
while [...] done < <( command this-file )
to see if it resolved the issue. If I do so, however, I have no way to
determine the exit status of 'command' in the parent shell, at least
in bash 4.2.

I have somewhat of a repeat-by now, but I want to see if it causes the
same hiccup in bash 4.2 as the original script did, because it doesn't
do it in bash 5.2. We shall see.