[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: questions about coproc

From: Koichi Murase
Subject: Re: questions about coproc
Date: Sun, 12 Mar 2023 21:14:20 +0900

2023年3月11日(土) 8:09 Britton Kerin <>:
> > 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.

Sorry, you are right! The stdin is already used to read from the pipe
set up by coproc.

> Yes, you are exactly right, and in fact it's that's getting it
> I think.  It also eats STDERR in general after:
>    [[ ${BLE_VERSION-} ]] && ble-attach
> I know this was mentioned in 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.

This place is the mailing list for Bash, and the above is off-topic
here. Let's move to the thread in For the record, It's at

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

Let me correct my mistake here for the other audience. The above line
needs to be something like

    bg_pid=$(perl ... >&"$fd_in" <&"$fd_out" & 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.

I hope so. The current version of coproc is particularly useful for an
independent shell program, but it'd be also useful for libraries and
interactive settings if the multiple coprocesses would be finally
ensured to work.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]