On 4/15/24 1:01 PM, Carl Edquist wrote:
On Sat, 13 Apr 2024, Chet Ramey wrote:
The original intent was to allow the shell to drive a long-running
process that ran more-or-less in parallel with it. Look at
examples/scripts/bcalc for an example of that kind of use.
Thanks for mentioning this example. As you understand, this model use case
does not require closing the coproc fds when finished, because they will be
closed implicitly when the shell exits. (As bcalc itself admits.)
And if the coproc is left open for the lifetime of the shell, the alternate
behavior of deferring the coproc deallocation (until both coproc fds are
closed) would not require anything extra from the user.
The bcalc example does close both coproc fds though - both at the end, and
whenever it resets. And so in this example (which as you say, was the
original intent), the user is already explicitly closing both coproc fds
explicitly; so the alternate deferring behavior would not require anything
extra from the user here either.
...
Yet another point brought to light by the bcalc example relates to the
coproc pid variable. The reset() function first closes the coproc pipe
fds, then sleeps for a second to give the BC coproc some time to finish.
An alternative might be to 'wait' for the coproc to finish (likely faster
than sleeping for a second).
If the coproc has some problem and doesn't exit immediately, `wait' without
options will hang. That's why I opted for the sleep/kill-as-insurance
combo.
(And before you ask why I didn't use `wait -n', I wrote bcalc in 30 minutes
after someone asked me a question about doing floating point math with awk
in a shell script, and it worked.)
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
