In article <vf0a1h$3sn0s$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 19.10.2024 13:45, Kenny McCormack wrote:

In article <vec3qb$3q4ms$3@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Fri, 11 Oct 2024 22:50:10 +0200, Frank Winkler wrote:

... but it still doesn't solve the issue that I need the result to be
visible in the parent shell.

coproc { uname -sr; }
read -u ${COPROC[0]} var3
wait $COPROC_PID
echo $var3

I'm actually a fan of "coproc" in bash, and I use it in my scripting, but I >> think it is overkill in most cases. [...]

Also, if above code is how to use co-processes in Bash, I consider
that extremely clumsy (if compared to, say, Ksh).

(Mileages may vary, of course.)

I think he was being intentionally verbose for pedagogic purposes.

I won't bore you with the details, but obviously a lot of the text in the quoted 4 lines is unnecessary in practice.

Just out of curiosity, how would you (Janis) do this in ksh?

--
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/ForFoxViewers

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19.10.2024 15:35, Kenny McCormack wrote:

In article <vf0a1h$3sn0s$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 19.10.2024 13:45, Kenny McCormack wrote:

In article <vec3qb$3q4ms$3@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Fri, 11 Oct 2024 22:50:10 +0200, Frank Winkler wrote:

... but it still doesn't solve the issue that I need the result to be >>>>> visible in the parent shell.

coproc { uname -sr; }
read -u ${COPROC[0]} var3
wait $COPROC_PID
echo $var3

I'm actually a fan of "coproc" in bash, and I use it in my scripting, but I >>> think it is overkill in most cases. [...]

Also, if above code is how to use co-processes in Bash, I consider
that extremely clumsy (if compared to, say, Ksh).

(Mileages may vary, of course.)

I think he was being intentionally verbose for pedagogic purposes.

I won't bore you with the details, but obviously a lot of the text in the quoted 4 lines is unnecessary in practice.

Just out of curiosity, how would you (Janis) do this in ksh?

For the question on topic I wouldn't (as you wouldn't, IIUC) use
co-processes in the first place - even if [in ksh] we don't need
file descriptor numbers from arrays (like in the bash sample).

I'd use one of the one-liner solutions if I hadn't the "lastpipe"
functionality built-in or available. It also makes no sense, IMO,
to use co-processes that just read a simple value from a command.

Co-processes I have to use only rarely, and the applications are
from commands that provide some "service"; I send a request, and
then I retrieve the response (and rinse repeat, as they say).

The syntax for the [unnecessary] co-process application depicted
above would in Ksh be

uname -sr |&
read -p var
echo "$var"


Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19.10.2024 15:54, Janis Papanagnou wrote:

Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

coproc { uname -sr; }
read -u ${COPROC[0]} var3
wait $COPROC_PID
echo $var3

The syntax for the [unnecessary] co-process application depicted
above would in Ksh be

uname -sr |&
read -p var
echo "$var"

Concerning the syntax (differences, and generally) I want to add
that it's worthwhile to compare the Ksh syntax with the approach
that we would typically take [in Ksh] to solve the task

uname -sr | read var
echo "$var"

We see that the co-process syntax is a straightforward variant of
the ordinary piping. (As opposed to bash that introduces a lot of
[bulky] stuff that's not even resembling in any way the read-pipe.)


For the interested folks let me hijack my post to add that it's
possible to redirect the co-processes to other file descriptors
(using <&p and >&p with appropriate file descriptor numbers) so
that multiple co-processes can be simultaneously used.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <vf0dn6$3t9fe$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 19.10.2024 15:35, Kenny McCormack wrote:

In article <vf0a1h$3sn0s$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

On 19.10.2024 13:45, Kenny McCormack wrote:

In article <vec3qb$3q4ms$3@dont-email.me>,
Lawrence D'Oliveiro <ldo@nz.invalid> wrote:

On Fri, 11 Oct 2024 22:50:10 +0200, Frank Winkler wrote:

... but it still doesn't solve the issue that I need the result to be >>>>>> visible in the parent shell.

coproc { uname -sr; }
read -u ${COPROC[0]} var3
wait $COPROC_PID
echo $var3

I'm actually a fan of "coproc" in bash, and I use it in my scripting,
but I think it is overkill in most cases. [...]

Also, if above code is how to use co-processes in Bash, I consider
that extremely clumsy (if compared to, say, Ksh).

(Mileages may vary, of course.)

I think he was being intentionally verbose for pedagogic purposes.

I won't bore you with the details, but obviously a lot of the text in the
quoted 4 lines is unnecessary in practice.

Just out of curiosity, how would you (Janis) do this in ksh?

For the question on topic I wouldn't (as you wouldn't, IIUC) use
co-processes in the first place - even if [in ksh] we don't need
file descriptor numbers from arrays (like in the bash sample).

Agreed.

I'd use one of the one-liner solutions if I hadn't the "lastpipe" >functionality built-in or available. It also makes no sense, IMO,
to use co-processes that just read a simple value from a command.

Agreed.

Co-processes I have to use only rarely, and the applications are
from commands that provide some "service"; I send a request, and
then I retrieve the response (and rinse repeat, as they say).

Agreed.

The syntax for the [unnecessary] co-process application depicted
above would in Ksh be

uname -sr |&
read -p var
echo "$var"

Which is pretty much the same as in bash, which would be:

coproc { uname -sr; }
read -u$COPROC
echo "$REPLY"

Note that bash can be compiled to support multiple concurrent coprocs. (*) Thus, it makes sense to have to explicitly specify the fd to read or write, rather than (AIUI), in ksh where there is just "the coproc".

The multi-coproc feature is off by default (in bash), but can be turned on
by setting an option in one of the config.h files and re-compiling bash.
It is considered "experimental", but seems to work OK as far as I can tell.

(*) You do this by giving the 2nd and subsequent coprocs names and then use that name instead of the default "COPROC" to access the I/O fds.

--
"The party of Lincoln has become the party of John Wilkes Booth."

- Carlos Alazraqui -

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

In article <vf239t$9ikn$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

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.

It has to do with certain habits/conventions that Usenet posters have
fallen into. One sees this frequently, where words like "very" and
"extremely" are dropped into one's phrasing for no particularly good
reason. You (Janis) are hardly alone in this habit, but it is something
that has frequently annoyed me about Usenet parlance.

There is a story on this subject (having to do with the journalistic
over-use of the word "very"), which I frequently quote in real life conversations, attributed to Mark Twain. I may yet end up telling that
story on this thread, but not right now.

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

My opinion, which I have stated consistently in this thread, is that it
doesn't add up to much difference - hence my criticism of your use of the
word "extremely". Addressing each of your points:
1) So what? |& vs. coproc. Who cares? I explained in another post
why (IMHO) they did it this way. As both me and LDO have noted, bash
supports multiple concurrent coprocs, so doing it this way is
necessary.

2) It is necessary. The syntax is admittedly a bit weird and not well
documented. If the thing you are launching as a coproc is anything
other than a single word command, then it has to be enclosed in {}.
For quite a while, I didn't know this, so as a workaround, I'd write
a function (say: foo()) then do: coproc foo

3&4&5) Necessary because bash supports multiple concurrent coprocs.
Also, as I've noted, you don't actually have to use array notation to
get the "read output from the coproc" fd.

6) Not necessary, and I've never used it in my code. As I have
mentioned in another post, I think LDO was being intentionally
pedantically complete in his example.

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 think there is no significant difference at all (*). See above.

(*) Other than that bash does support multiple concurrent coprocs (if you
are willing to recompile bash).

...

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

As noted elsethread, bash took |& from csh (*). So, they had to come up
with something else for coprocs.

(*) I don't think this was a particularly bright move on their part, BTW.
I never use it; I always use the more normal "2>&1" syntax.

...

No comment on the rest, other than to say that you seem to claim that ksh
does support multiple concurrent coprocs, which I think is wrong, but I
think we may not be talking about the same thing (so probably not much
point in continuing in that vein).

--
Conservatives want smaller government for the same reason criminals want fewer cops.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 20.10.2024 11:12, Kenny McCormack wrote:

In article <vf239t$9ikn$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

I don't think it makes much sense to discuss subjective valuations.
But okay.

It has to do with certain habits/conventions that Usenet posters have
fallen into. [...]

Okay.

[...]

No comment on the rest, other than to say that you seem to claim that ksh does support multiple concurrent coprocs, which I think is wrong, [...]

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. I just hacked a sample to show what I mean...

bc |&
exec 3<&p 4>&p
bc -l |&
exec 5<&p 6>&p

while IFS= read -r line
do
case ${line} in
(*[.]*)
print -u6 "$line"
read -u5 res
print "Res(R): $res"
;;
(*)
print -u4 "$line"
read -u3 res
print "Res(I): $res"
;;
esac
done

(The second 'exec' isn't necessary for the last started coprocess
since you can use options '-p' as with a single coprocess instead
of the -u5 and -u6, but you see that there's in principle arbitrary
numbers of coprocesses possible.)

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 25.10.2024 06:35, Lawrence D'Oliveiro 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.

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.

But my response was anyway just countering the (wrong) opinion
that it would not be possible in Ksh.

There's no more to be said on my part.

Janis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

No comment on the rest, other than to say that you seem to claim that ksh
does support multiple concurrent coprocs, which I think is wrong, [...]

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. I just hacked a sample to show what I mean...

OK. Got it. That's how you would do it in ksh.

I think I like the bash way better, but we are just discussing details at
this point.

(Nice example, BTW)
--
I've been watching cat videos on YouTube. More content and closer to
the truth than anything on Fox.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)