Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.unix.shell
Subject: Re: Subjective "valuations" are all we have (Was: coprocs - again
 (Was: Different variable assignments))
Date: Fri, 25 Oct 2024 11:32:02 +0200
Organization: A noiseless patient Spider
Lines: 98
Message-ID: <vffoij$349j2$1@dont-email.me>
References: <lmt83dFsvbvU3@mid.individual.net> <vff6l8$31j2u$1@dont-email.me>
 <vff775$31l9b$1@dont-email.me> <vff8qc$31tk9$1@dont-email.me>
 <vffjp3$3l9t2$1@news.xmission.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 25 Oct 2024 11:32:04 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="b0051abdce59c21a789bf51cbdb0a4ac";
	logging-data="3286626"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+CZphMJKwT6iGuSiF2lSqo"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:c6uR3f68DUHW6F379S/M6pgjPc0=
X-Enigmail-Draft-Status: N1110
In-Reply-To: <vffjp3$3l9t2$1@news.xmission.com>

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

> [...]