In article <vff775$31l9b$1@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>On Fri, 25 Oct 2024 06:26:14 +0200, Janis Papanagnou wrote:
>
>> I meant that you can have several asynchroneous processes started which
>> are each connected to the same main shell session with pipes for
>> communicating. For that you have to redirect the default pipe channels
>> because there's of course just one option '-p' with the commands 'read'
>> and 'print' and you need some way to differentiate the various channels.
>
>Bash does that in a nicer way.

Agreed.

--
The people who were, are, and always will be, wrong about everything, are still
calling *us* "libtards"...

(John Fugelsang)

In article <vfeimj$2qggf$3@dont-email.me>,
Lem Novantotto <Lem@none.invalid> wrote:
....
>| $ openconnect -b unresponsive:local:ip:address | tee | grep .

Note that "tee" when run with no args is a no-op.
It is, in fact, equivalent to running "cat" (with no args).

--
I am not a troll.
Rick C. Hodgin
I am not a crook.
Rick M. Nixon

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".

It was you who first brought up your personal opinion on the subject
(comparing the ksh implementation of coprocs with the bash implementation).
To be clear, there is nothing wrong with that; we are here to exchange
opinions.

I really do think that there's no significant difference in verbosity
between the two implementations (certainly in the simple case). 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".

And, finally, yes, it is odd that the bash way was designed to support
multi-coproc yet multi-coproc doesn't work "out of the box" (I've described
elsethread what you have to do to get it to work). Maybe this situation
has changed in the years since I last researched it.

--
The randomly chosen signature file that would have appeared here is more than 4
lines long. As such, it violates one or more Usenet RFCs. In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
http://user.xmission.com/~gazelle/Sigs/Aspergers

Il Fri, 25 Oct 2024 07:10:35 -0000 (UTC), Kenny McCormack ha scritto:

> Note that "tee" when run with no args is a no-op.

Of course. :)
--
Bye, Lem

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

> [...]

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

In article <vffoij$349j2$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
....
>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.

I have no further comment on the issues you seem to have with the bash
implementation of coprocs. I think I've explained everything (more than
once) already in these threads.

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

Don't be afraid. Sometimes people are attracted to "just grew". They like
and admire that organic look. I really do think that ksh's implementation
of coprocs has an "organic" look. As I said, bash's way seems much more
"designed".

P.S. To answer one question, "coproc" *is* a shell keyword in bash:

$ type coproc
coproc is a shell keyword
$

I think you will find that |& is also a keyword (in ksh), although I could
not get "type" (or anything similar) to confirm that suspicion.

--
There's nothing more American than demanding to carry an AR-15 to
"protect yourself" but refusing to wear a mask to protect everyone else.

On 25.10.2024 14:54, Kenny McCormack wrote:
>
> P.S. To answer one question, "coproc" *is* a shell keyword in bash:

Yes. - I just asked that to get a better feeling for the implications,
e.g. for the redirection question that arose in Bash context. (Lem had
addressed that question in his post; a possible reason why redirection
is explicitly listed in the Bash man page with 'coproc'.)

> [...]
>
> I think you will find that |& is also a keyword (in ksh),

In Ksh it's not that relevant "what it is" because it's (syntactically
more obvious) a command separation like ';', <NL>, or '&'.
It's documented, and you can also see that if you write (for example)
bc |& exec 3<&p 4>&p
instead of having the two commands each in an own line.

In Ksh we write 'cmd &|' for a co-process as we write 'cmd &' for a
background process.[*]

> although I could
> not get "type" (or anything similar) to confirm that suspicion.

I don't think it makes sense to use the 'type' command on syntactic
symbols like ';', '&', '|&', '|', etc. - It's anyway documented in the
man page:

A list is a sequence of one or more pipelines separated by ;, &, ⎪&,
&&, or ⎪⎪, and optionally terminated by ;, &, or ⎪&.

Janis

In article <83y12u2xyt.fsf@helmutwaitzmann.news.arcor.de>,
Helmut Waitzmann <oe.throttle@xoxy.net> wrote:
....
>
> uname -sr | { read var3 ; echo $var3 ; }
>

More simply;

uname -sr

--
If Jeb is Charlie Brown kicking a football-pulled-away, Mitt is a '50s
housewife with a black eye who insists to her friends the roast wasn't
dry.

Il Fri, 15 Nov 2024 10:58:37 -0000 (UTC), Kenny McCormack ha scritto:

> In article <83y12u2xyt.fsf@helmutwaitzmann.news.arcor.de>,
> Helmut Waitzmann <oe.throttle@xoxy.net> wrote:
> ...
>>
>> uname -sr | { read var3 ; echo $var3 ; }
>>
>>
> More simply;
>
> uname -sr

LOL!
That was funny, thanks. :-D
--
Bye, Lem