Re: Different variable assignments

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.

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?).

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 also think that syntaxes that resemble existing constructs serves
"simplicity". Like using '|&', which resembles both, the pipelining
communication part '|', and the asynchronicity of the call '&'. It's
also visible (as already shown elsethread) in the similarity of the
calling syntax contexts; compare
  uname -sr | read
versus
  uname -sr |& read -p

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

Of course per bash's defaults even the simple 'uname -sr | read' has
to be written (for example) as 'uname -sr | { read ; echo $REPLY ;}'
i.e. with the spurious braces in case you want to access the value,
so the the added 'coproc { ;}' complexity in Bash might not look too
bad to Bash users, where Ksh users (like me) will probably value it
differently.

(It's also noteworthy that a common tool like GNU Awk also uses the
same token for its co-process feature which serves comprehensibility
and makes it "simple" to use on another "level of consideration".)

 

Bash allows for named coprocs. That means you can have multiple coprocs
going at once.

Note, that's possible in Ksh as well. Ksh's design decision is that
the common case (using one co-process) is "extremely" simple to use
and doesn't add unnecessary complexity or rises questions on details.

(And using multiple co-processes isn't difficult either with using
the known shell's redirections concept.)

[...]
 
But, yes, that's part of the point of making it possible to assign a name
to a coproc (instead of just taking the default of "coproc").

(Given how [supposedly] rare this feature is used, and that we were
speaking about subjective impressions, we have to assess that this
post got far too long. And probably triggers more dispute. Well...)

Janis

[*] Would it be possible to write a simplified form like
  'coproc uname -sr;'
or is it syntactically necessary to write
  'coproc { uname -sr; }'
?