Re: Subjective "valuations" are all we have (Was: coprocs - again (Was: Different variable assignments))

On 25.10.2024 10:10, Kenny McCormack wrote:

In article <vff8qc$31tk9$1@dont-email.me>,
Janis Papanagnou  <janis_papanagnou+ng@hotmail.com> wrote:
...

For multiple co-processes you may be right. (I certainly differ
given how Bash implemented it, with all the question that arise.)
And I already said: I don't think it makes much sense to discuss
subjective valuations.

 
Our opinions are all we have.  I can't see how that can be "off topic".

Oh, don't get me wrong; to each his own [opinion]. That's fine.

It's certainly also not off-topic, but it's just opinion. Though the
other poster also didn't provide any examples or rationales for his
opinion - which is not surprising if you know him - where I tried to
explain my POV; whether you support it or disagree to.

I can extend on what I already hinted upthread...

[...]
 
I really do think that there's no significant difference in verbosity
between the two implementations (certainly in the simple case).

Verbosity was not my point. (Only that I was repelled by the other
poster's, as far as I understand, unnecessary ballast in his code.)

But clearness or fitting into existing shell concepts do matter, IMO.

The ksh
way of handling multiples looks kludgey to me (you may think otherwise, of
course).  It certainly looks to me that the bash way was designed (no doubt
benefiting from ksh having paved the way), whereas the ksh way "just grew".

Well, the Bash way looks quite "hacky" in my opinion. But maybe you
could explain what I might have missed. The questions I'd have are
(for example); [from the bash man page] in

  coproc [NAME] command [redirections]

what is the 'coproc' actually (beyond a "reserved word")? Is it a
shell construct like, say, a 'case' construct, or a command, like,
say, 'pty' or 'time'? Then, depending on that; is the redirection
part of a special case here? And that's the reason why it's listed
explicitly? Note redirection is an orthogonal concept! Here too?
The access to the FDs is implicitly defined by 'COPROC[0]' for
"output" to the process and 'COPROC[1]' for input to the process;
is this coherent with 'stdin'(0) and 'stdout'(1); this at least
irritates me, it's not as obvious as it could be.

In Ksh I have the simple case that you can simply use

  command |&

  print -p
  read -p

Easy to use, clear, no ballast, no questions [to me].

If you want to redirect it with explicit FD control you use Ksh's

  exec 3<&p 4>&p

(and then 'read -u3' and 'print -u4' to communicate) for example.

Or you want Ksh to choose the FDs, then use variables (as you can
also generally do with non-coprocess related redirections) like

  exec {IN}<&p {OUT}>&p

(with arbitrary variable names, here IN and OUT chosen, which looks
more sophisticated to me than 'COPROC[0]' and 'COPROC[1]'). And you
can use the variables then simply as you're used to from other cases

  print -u $OUT
  read -u $IN

This fits well in Ksh's redirection feature set. And I suppose Bash
does not support FD variables, since the 'COPROC' (or own variables)
in this specific ("hacky") context needs to be introduced? - Or am I
mistaken that this is a 'coproc'-specific hack? - Bash's construct
[to me] looks flange-mounted (hope that is the correct word to use).

This post should also explain why I think that your valuation that
in Ksh the feature "just grew" is not justified. Beyond the '|&' vs.
'coproc' reserved word; consistency with '|' and '&', redirection,
assigned FDs (if desired), consistent 'p' as read/print option and
as FD, all fits and allows for readable straightforward code in Ksh
that also doesn't leave me with questions.

BTW, co-processes were designed into the shell with Ksh88 already;
not much to "just grow" (as you insinuated). ;-)

Janis

[...]