Re: questions about coproc

[Britton Kerin]

On Thu, Mar 9, 2023 at 2:10 PM Koichi Murase <myoga.murase@gmail.com> wrote:
>
> 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 <().

I think if you want to use stdin to perl process in the script itself
you need to get script in some other way, unless there is a trick here
I don't know.

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

Yes, you are exactly right, and in fact it's ble.sh that's getting it
I think.  It also eats STDERR in general after:

   [[ ${BLE_VERSION-} ]] && ble-attach

I know this was mentioned in ble.sh docs but I've still managed to
confuse myself with it a couple times now with e.g. typos in bleopt
that seem to need to follow ble-attach.  Is there a way to avoid this
effect?  I've thought of putting all the config that seems to need to
follow ble-attach in hooks or something then make ble-attach the very
last line of ~/.bashrc but I'm not sure it would work.

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

Ah so you were the one contradicting the more blase descriptions of
the situation I ran into.  The SIGPIPE argument sounds pretty
convincing that explicit cleanup is needed.

> > 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 "$!")

This is a fine approach but coproc seems to be trying to offer a
slightly more encapsulated solution, which for casual or occasional
shell programmers is attractive.  I hope it gets continued
development.

>
> 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; }
>   $

I'm honestly not sure what I was looking at that seemed to be coproc
ignoring job control, probably IO deadlock or so and careless
reporting on my part.  Sorry.

Britton