coprocs - again (Was: Different variable assignments)

In article <vf239t$9ikn$1@dont-email.me>,
Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:

On 20.10.2024 00:56, Kenny McCormack wrote:

In article <vf1942$1uso$1@dont-email.me>,
Lawrence D'Oliveiro  <ldo@nz.invalid> wrote:

On Sat, 19 Oct 2024 14:52:01 +0200, Janis Papanagnou wrote:
>

Also, if above code is how to use co-processes in Bash, I consider that
extremely clumsy (if compared to, say, Ksh).

 
"extremely" seems more than a bit over the top.  Maybe somewhat clumsy, but
hardly "extremely".

>
I don't think it makes much sense to discuss subjective valuations.
But okay.

It has to do with certain habits/conventions that Usenet posters have
fallen into.  One sees this frequently, where words like "very" and
"extremely" are dropped into one's phrasing for no particularly good
reason.  You (Janis) are hardly alone in this habit, but it is something
that has frequently annoyed me about Usenet parlance.

There is a story on this subject (having to do with the journalistic
over-use of the word "very"), which I frequently quote in real life
conversations, attributed to Mark Twain.  I may yet end up telling that
story on this thread, but not right now.

Mine stems from a "per-feature level" (and is no absolute). It was
based on LDO's suggestion (which was a bit more complex than your
version) that used; (1) a [new] keyword, (2) command grouping (not
sure it's necessary[*] in the first place?), (3) using an explicit
descriptor through (4) a variable, (5) using an array instead of a
scalar element, and (6) using 'wait' (I'm also not sure this is
necessary in the first place or just the poster not knowing better?).

My opinion, which I have stated consistently in this thread, is that it
doesn't add up to much difference - hence my criticism of your use of the
word "extremely".  Addressing each of your points:
    1) So what?  |& vs. coproc.  Who cares?  I explained in another post
    why (IMHO) they did it this way.  As both me and LDO have noted, bash
    supports multiple concurrent coprocs, so doing it this way is
    necessary.

    2) It is necessary.  The syntax is admittedly a bit weird and not well
    documented.  If the thing you are launching as a coproc is anything
    other than a single word command, then it has to be enclosed in {}.
    For quite a while, I didn't know this, so as a workaround, I'd write
    a function (say: foo()) then do: coproc foo

    3&4&5) Necessary because bash supports multiple concurrent coprocs.
    Also, as I've noted, you don't actually have to use array notation to
    get the "read output from the coproc" fd.

    6) Not necessary, and I've never used it in my code.  As I have
    mentioned in another post, I think LDO was being intentionally
    pedantically complete in his example.

For a simple feature that's really a lot compared to e.g. ksh's way.
(YMMV. But if "somewhat clumsy" triggers less emotions then I'm fine
with that.)

I think there is no significant difference at all (*).  See above.

(*) Other than that bash does support multiple concurrent coprocs (if you
are willing to recompile bash).

...

(Yes, '|' is different than '|&', which is more like '&' since it
separates commands where the pipe connects them. But that was not
the point here.)

As noted elsethread, bash took |& from csh (*).  So, they had to come up
with something else for coprocs.

(*) I don't think this was a particularly bright move on their part, BTW.
I never use it; I always use the more normal "2>&1" syntax.

...

No comment on the rest, other than to say that you seem to claim that ksh
does support multiple concurrent coprocs, which I think is wrong, but I
think we may not be talking about the same thing (so probably not much
point in continuing in that vein).

--
Conservatives want smaller government for the same reason criminals want fewer cops.