[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: questions about coproc
From: |
Britton Kerin |
Subject: |
Re: questions about coproc |
Date: |
Fri, 10 Mar 2023 14:08:52 -0900 |
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