Re: questions about coproc

[Koichi Murase]

2023年3月10日(金) 3:48 Britton Kerin <britton.kerin@gmail.com>:
> First let me say coproc is quite nifty, thanks for implementing!
>
> One thing I've done is make a small regex server for bash using perl:
>
> coproc perl_regex_server {
>   perl <(cat <<'  END_PERL'
>   ...
>   END_PERL
>   )
> }

It's irrelevant to the present discussion, but I think you can
directly supply the script to stdin of perl without using a process
substitution <().

  coproc perl_regex_server {
    perl <<'  END_PERL'
    ...
    END_PERL
  }

> 1.  no obvious way to propagate e.g. the die argument in the above
> back to the controlling terminal.  Is there some easy way to do this
> that I missed?

coproc redirects stdin and stdout but doesn't redirect stderr. The
output of `die' seems to propagate to TTY as far as I test it.

  $ coproc a { perl <<< "die 'xxxxx';"; }
  [1] 1584306
  $ xxxxx at - line 1.

  [1]+  Exit 9                  coproc a { perl <<< "die 'xxxxx';"; }

Maybe stderr is redirected to /dev/null or somewhere in your whole setup?

> 2.  If the above job has been created from e.g. ~/.bashrc, then when I
> try to make another coproc I get an error like this on the terminal:
>
>      bash: warning: execute_coproc: coproc [11142:perl_regex_server]
> still exists
>
> The new coproc seems to exist and work, but this error is worrisome
> and would be very confusing to a user who wasn't aware of this coproc.

With the default build of Bash, full support for coproc (including
desired cleanup, etc. [1], I guess) is only provided for up to one
instance. So, a framework/library or settings in bashrc shouldn't use
a coproc in order not to affect the environment of the main program or
the user's environment.

[1] https://lists.gnu.org/archive/html/help-bash/2021-03/msg00282.html

> 3.  I don't really like seeing it as a job in job control.

I'm not sure for the ``appropriate design'' of Bash, but as a
practical solution to 2 and 3, I'd set up pipes by myself and start a
background job from a subshell. You need to be careful for the
cleanup, proper management of the named pipes on the filesystem, etc.,
but the essential idea can be summarized in the following code:

  mkfifo a.pipe b.pipe
  exec {fd_in}<> a.pipe {fd_out}<> b.pipe
  bg_pid=$(perl ... & echo "$!")

Ref. [2] is an actual example, though it is still in the testing stage:

[2] 
https://github.com/akinomyoga/blesh-contrib/blob/b4978f8126bcd478e5fb5657be7806e2a672b217/histdb.bash#L229-L233

> I wonder
> if it might be appropriate to have an option to hide from the job
> control list, or hide unless some option to jobs is given.  It's isn't
> like other jobs and can't really be controlled in the same way.

I'm not sure if it doesn't cause any other problems, but coprocs seem
to be able to control in the same way as normal jobs under the job
control at least for some operations:

  $ coproc a { echo hello; sleep 5; exit 123; }
  [1] 1585551
  $ fg
  coproc a { echo hello; sleep 5; exit 123; }
  $ bg
  [1]+ coproc a { echo hello; sleep 5; exit 123; } &
  $
  [1]+  Exit 123                coproc a { echo hello; sleep 5; exit 123; }
  $

> Or
> maybe it could be in it's own section of the list and not take up job
> number 1 or something.

Even if we do not use the job control, we can still use the job number
for some job operations such as wait and kill.

  $ coproc a { echo hello; sleep 5; exit 123; }
  [1] 1585503
  $ wait %1
  [1]+  Exit 123                coproc a { echo hello; sleep 5; exit 123; }
  $

--
Koichi