Path: ...!news.snarked.org!xmission!nnrp.xmission!.POSTED.shell.xmission.com!not-for-mail
From: gazelle@shell.xmission.com (Kenny McCormack)
Newsgroups: comp.unix.shell
Subject: coprocs - again (Was: Different variable assignments)
Date: Sun, 20 Oct 2024 09:12:36 -0000 (UTC)
Organization: The official candy of the new Millennium
Message-ID: <vf2hi4$3en6a$1@news.xmission.com>
References: <lmt83dFsvbvU3@mid.individual.net> <vf1942$1uso$1@dont-email.me> <vf1dfl$3e4c7$1@news.xmission.com> <vf239t$9ikn$1@dont-email.me>
Injection-Date: Sun, 20 Oct 2024 09:12:36 -0000 (UTC)
Injection-Info: news.xmission.com; posting-host="shell.xmission.com:166.70.8.4";
	logging-data="3628234"; mail-complaints-to="abuse@xmission.com"
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: gazelle@shell.xmission.com (Kenny McCormack)
Bytes: 4864
Lines: 85

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.