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. The most general command for variable
assignment (in bash) is "mapfile". "mapfile" supercedes "coproc" in most
cases. For the possible benefit of OP, here's the standard idiom for using
"mapfile", using the "sw_vers" program, which OP mentioned in passing
(AFAIK, "sw_vers" is a Mac OS thing):

mapfile -t < <(sw_vers)

which populates the array MAPFILE.

A couple of other points:
1) When using "coproc", you can get away with just $COPROC for the
output of the co-process. This is a little easier to type than
${COPROC[0]} - even if this does get flagged as a warning by the
"shellcheck" program. Note that in bash, all variables are arrays;
it's just that most only have one element:
% bash -c 'echo ${HOME[0]}'
/home/me
%

2) OP's main concern actually seems to be aesthetic. He just wants the
variable name at the end of the line instead of at the beginning. Kind
of like the difference between the two styles of assembler languages,
where some are: "move src,dst" and others (most) are "move dst,src".
(It's been a long time since I've done assembler language.)

Finally, note that you just generally learn to avoid the (wrong) idiom of:

cmd | read bar

because you learn early on that it doesn't work. I think the most basic
(works in any sh-like shell, even in the bad old days of Solaris)
alternative is:

read bar << EOF
$(cmd)
EOF

--
https://www.rollingstone.com/politics/politics-news/the-10-dumbest-things-ever-said-about-global-warming-200530/

RS contributor Bill McKibben lambasted this analysis in his 2007 book, Deep Economy.
It's nice to have microelectronics; it's necessary to have lunch, wrote McKibben.

In article <veeag0$786f$2@dont-email.me>,
Lem Novantotto <Lem@none.invalid> wrote:
....
>But my command doesn't work instead, in bash. That's why:
>
>| lastpipe
>| If set, and job control is not active, the shell runs the last command
>| of a pipeline not executed in the background in the current shell
>| environment.

The key phrase here is "job control is not active". AFAICT, "lastpipe" (bash)
works in a script, but not interactively.

--
You know politics has really been turned upside down when you have someone in the
government with a last name of Cheney (Liz, Senator from Wyoming) who is the voice of
reason.

In article <vecl6n$d0r$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
....
>(In other shells you have to work around the issue as demonstrated in
>other answers to your post. Some workaround are more clumsy some less.

Setting "lastpipe" works (sort of) in bash.

>A shorter variant of the here-document posted elsethread can be using
>here-strings
>
>$ read var <<< $(uname -a)
>
>another method is using process substitution and redirection
>
>$ read var < <(uname -a)
>
>Both supported by shells like ksh, bash, zsh, but non-standard as are
>some other workaround proposals that use bash-specifics like 'coproc',
>that doesn't work as widely as using '<<<' or '<(...)' do.)

There are lots of workarounds, but I think the main takeaway is that the
obvious-but-wrong idiom of "cmd | read foo" is just TBA.

--
Life's big questions are big in the sense that they are momentous. However, contrary to
appearances, they are not big in the sense of being unanswerable. It is only that the answers
are generally unpalatable. There is no great mystery, but there is plenty of horror.
(https://en.wikiquote.org/wiki/David_Benatar)

On 19.10.2024 12:45, Kenny McCormack wrote:
> In article <vecmp3$pur$1@dont-email.me>,
> Lawrence D'Oliveiro <ldo@nz.invalid> wrote:
>> On Sat, 12 Oct 2024 03:59:49 +0200, Janis Papanagnou wrote:
>>
>>> ... use bash-specifics like 'coproc' ...
>>
>> It isn't bash-specific.

Maybe; I haven't checked all existing shells. I know that the keyword
is not used in Kornshell. I know it's used in bash. I don't know, e.g.,
about zsh, the other major shell I'm also interested in.

>
> People on these newsgroups often use phrases like "bash specific" as
> synonyms for "Not strictly POSIX" (*), even though the bash feature under
> discussion is also found in other shells. In fact, many bash-isms,
> including "coproc", came originally from ksh. I'm sure Janis knows this.

Please note that while ksh supports co-processes it doesn't use (to my
knowledge) the keyword 'coproc'. - Kornshells co-processes are invoked
by appending the '|&' token to a command and reads and writes are done
with 'read -p' and 'print -p', respectively.

Janis

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

Janis

Il Sat, 19 Oct 2024 11:47:16 -0000 (UTC), Kenny McCormack ha scritto:

> AFAICT, "lastpipe" (bash)
> works in a script, but not interactively.

Uhm... I'm sorry, probably I do not get your point. It's a bash
shell option: you set it (or unset it), and then you go.

| $ set -m ; shopt -u lastpipe ; unset my
| $ echo ciao |read my ; echo $my
|
| $ set +m ; shopt -s lastpipe ; unset my
| $ echo ciao |read my ; echo $my
| ciao

--
Bye, Lem

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

In article <vf08fi$3sf5e$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
....
>Please note that while ksh supports co-processes it doesn't use (to my
>knowledge) the keyword 'coproc'. - Kornshells co-processes are invoked
>by appending the '|&' token to a command and reads and writes are done
>with 'read -p' and 'print -p', respectively.

Seems to be pretty much the same thing, but with a slightly different
notation (|& vs. "coproc"). I think the original bash designers wanted to
be at least sort of "csh compatible", so they took |& from csh to mean
"merge stdout and stderr", so had to come up with something else for
coprocs.

Anyway, all I know about ksh is basically what I've read from various bash
sources.

--
"We are in the beginning of a mass extinction, and all you can talk
about is money and fairy tales of eternal economic growth."

- Greta Thunberg -

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

On 19.10.2024 15:39, Kenny McCormack wrote:
> In article <vf08fi$3sf5e$1@dont-email.me>,
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
> ...
>> Please note that while ksh supports co-processes it doesn't use (to my
>> knowledge) the keyword 'coproc'. - Kornshells co-processes are invoked
>> by appending the '|&' token to a command and reads and writes are done
>> with 'read -p' and 'print -p', respectively.
>
> Seems to be pretty much the same thing, but with a slightly different
> notation (|& vs. "coproc"). I think the original bash designers wanted to
> be at least sort of "csh compatible", so they took |& from csh to mean
> "merge stdout and stderr", so had to come up with something else for
> coprocs.

Ah, I see. (Although "csh compatible" in scripting is, erm, somewhat
disturbing.)

Janis

> [...]

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

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 -

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

Bash allows for named coprocs. That means you can have multiple coprocs
going at once.

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

>Bash allows for named coprocs. That means you can have multiple coprocs
>going at once.

Yes, but only if you re-compile your own version of bash, with that option
turned on in one of the config.h files.

To be precise, multiple co-procs will seem to work even if not enabled as
described above, but things then start to go awry in mysterious ways. I've
experienced exactly this until I did the research into how to properly
enable it.

But, yes, that's part of the point of making it possible to assign a name
to a coproc (instead of just taking the default of "coproc").

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

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.

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

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 also think that syntaxes that resemble existing constructs serves
"simplicity". Like using '|&', which resembles both, the pipelining
communication part '|', and the asynchronicity of the call '&'. It's
also visible (as already shown elsethread) in the similarity of the
calling syntax contexts; compare
uname -sr | read
versus
uname -sr |& read -p

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

Of course per bash's defaults even the simple 'uname -sr | read' has
to be written (for example) as 'uname -sr | { read ; echo $REPLY ;}'
i.e. with the spurious braces in case you want to access the value,
so the the added 'coproc { ;}' complexity in Bash might not look too
bad to Bash users, where Ksh users (like me) will probably value it
differently.

(It's also noteworthy that a common tool like GNU Awk also uses the
same token for its co-process feature which serves comprehensibility
and makes it "simple" to use on another "level of consideration".)

>
>> Bash allows for named coprocs. That means you can have multiple coprocs
>> going at once.

Note, that's possible in Ksh as well. Ksh's design decision is that
the common case (using one co-process) is "extremely" simple to use
and doesn't add unnecessary complexity or rises questions on details.

(And using multiple co-processes isn't difficult either with using
the known shell's redirections concept.)

> [...]
>
> But, yes, that's part of the point of making it possible to assign a name
> to a coproc (instead of just taking the default of "coproc").

(Given how [supposedly] rare this feature is used, and that we were
speaking about subjective impressions, we have to assess that this
post got far too long. And probably triggers more dispute. Well...)

Janis

[*] Would it be possible to write a simplified form like
'coproc uname -sr;'
or is it syntactically necessary to write
'coproc { uname -sr; }'
?

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.

On 15.10.2024 13:46, I wrote:

>The thing in question does
>
>tty=`tty`
>sudo openconnect -b ... |\
>   tee $tty | grep "^Session authentication will expire at" |\
>   cut -d ' ' -f 7- | read end
>
>and this completely fails. Terminal output is missing, $end is empty and
>the whole command doesn't seem to work. Without the last two lines, it's
>working perfectly.
>"sudo" also doesn't seem to be the problem as simple tests are working.

After some more testing with just a "tee" into a file, it looks like the
pipe starts OC and writes its output (including the part I want to
"grep" in to the file but then hangs. Everything following this line in
the script doesn't seem to be done, anyway. Maybe some effect of the
background option?

Regards

fw

In article <lnuidqFk4dU1@mid.individual.net>,
Frank Winkler <usenet@f.winkler-ka.de> wrote:
>On 15.10.2024 13:46, I wrote:
>
> >The thing in question does
> >
> >tty=`tty`
> >sudo openconnect -b ... |\
> > tee $tty | grep "^Session authentication will expire at" |\
> > cut -d ' ' -f 7- | read end
> >
> >and this completely fails. Terminal output is missing, $end is empty and
> >the whole command doesn't seem to work. Without the last two lines, it's
> >working perfectly.
> >"sudo" also doesn't seem to be the problem as simple tests are working.
>

OK, let's try to normalize this. But first, please tell which shell you
are targeting. I.e., how much old-compatibility do you need?

I'm going to assume bash, but there isn't much difference. In particular,
note that $() is POSIX, so you really don't need to ever mess with ``.

Also note: You do not need \ at the end of the line if the line ends with |
(also true for lines that end with || or && - and possibly others)

Anyway, this should do it:

tty=$(tty)
end="$(sudo openconnect -b ... |
tee $tty | grep "^Session authentication will expire at" |
cut -d ' ' -f 7-)"

Note also that the grep and the cut could be merged into a single
invocation of awk - but I don't know enough about what you're doing to be
more specific. You can probably also eliminate all of the "tty" stuff by
writing either to /dev/tty (which is generic Unix) or /dev/stderr (which
might be Linux-specific). Also, if you use gawk (GNU awk), then you can
write to /dev/stderr from within AWK and eliminate all of the "tee" stuff
as well.

--
"Remember when teachers, public employees, Planned Parenthood, NPR and PBS
crashed the stock market, wiped out half of our 401Ks, took trillions in
TARP money, spilled oil in the Gulf of Mexico, gave themselves billions in
bonuses, and paid no taxes? Yeah, me neither."

On 24.10.2024 13:21, Kenny McCormack wrote:

>I'm going to assume bash, but there isn't much difference. In
particular,
>note that $() is POSIX, so you really don't need to ever mess with ``.

I know that "$()" is POSIX but I don't feel "``" as a mess but in fact,
I like it much better. And we're talking about ksh.

>Also note: You do not need \ at the end of the line if the line ends
with |
>(also true for lines that end with || or && - and possibly others)
>
>Anyway, this should do it:
>
> tty=$(tty)
> end="$(sudo openconnect -b ... |
> tee $tty | grep "^Session authentication will expire at" |
> cut -d ' ' -f 7-)"

I also know that the "``" thing should and does do it but I explicitly
asked why the "read" approach fails and that I'd prefer a solution with
the assignment at the end.

You're absolutely right that there's probably a more elgant and cooler
way instead of "grep" and "cut" (maybe with "awk") but that was a quick
one and the details can be optimized when things are working. But thanks
for the ideas.

Regards

fw

Il Thu, 24 Oct 2024 11:30:34 +0200, Frank Winkler ha scritto:

> Maybe some effect of the background option?

I guess it could be so.

However, since I don't use openconnect I could only try something like:

| $ openconnect -b unresponsive:local:ip:address | tee | grep .
| POST https://192.168.38.38/
| Failed to connect to host 192.168.38.38
| Failed to open HTTPS connection to 192.168.38.38
| Failed to complete authentication
| Failed to connect to 192.168.38.38:443: Nessun instradamento per l'host

which works, and in bash gives me the stderr printed by openconnect - the
three lines in the middle - and the stdout (piped from openconnect to tee
and then from tee to grep) printed in red by grep - first and last line).
In ksh no red color, but it works the same.

Then, in standard bash:

|$ openconnect -b 192.168.38.38 2>&1 | tee | grep -o POST |read end ; \
|> echo $end
|

whilst in ksh:

|$ openconnect -b 192.168.38.38 2>&1 | tee | grep -o POST |read end ; \
|> echo $end
POST

Again, it works as expected. So I didn't come to anything useful. Sorry.
--
Bye, Lem

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

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.

On 24.10.2024 23:43, Frank Winkler wrote:
> On 24.10.2024 13:21, Kenny McCormack wrote:
>
> >I'm going to assume bash, but there isn't much difference. In
> particular,
> >note that $() is POSIX, so you really don't need to ever mess with ``.
>
> I know that "$()" is POSIX but I don't feel "``" as a mess but in fact,
> I like it much better. And we're talking about ksh.
>
> [...]
>
> I also know that the "``" thing should and does do it but I explicitly
> asked why the "read" approach fails and that I'd prefer a solution with
> the assignment at the end.

The posts have indicated that folks here were trying to clarify
what you [intended to] do. Kenny was suggesting some basic things
that you should indeed consider adapting to make your programs
clearer and less error-prone. Of course you can do what you like.
But you should really consider the "new" (i.e. 1988) syntax for
command substitution that Ksh had invented for documented reasons.

Janis

> [...]

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

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.