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

Il Fri, 25 Oct 2024 11:32:02 +0200, Janis Papanagnou ha scritto:

what is the 'coproc' actually (beyond a "reserved word")?

Just to clarify it to myself: I'd say that 'coproc' is a reserved word
that introduces a command (simple or compound). The command introduced by
the reserverd word 'coproc' is called *coprocess*.
So coproc is a reserved word, a coprocess is a command... and to me
"coproc command" is a shell construct. Kind of.

And coproc is just the bash builtin way to realize a two-way fifo named
pipe, besides the command mkfifo.

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?

I think it's listed explicitly just to remark the order of creation: the
coproc two-way pipe is created *before* any other redirections.

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.

I'd agree with you... and indeed I do! But since we have a two-way pipe,
the input of the coprocess is on the output of the executing shell, and
vice-versa. So maybe it's just a matter of... where do you look it from?
And if you look it from the executing shell... bah, dunno why it's the way
it is.

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]').

Agreed. IMHO the capability to well differentiate names for input and
output is a plus.
--
Bye, Lem