help-bash
[Top][All Lists]
Advanced

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

Re: questions about coproc


From: Chet Ramey
Subject: Re: questions about coproc
Date: Tue, 14 Mar 2023 10:40:00 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.8.0

On 3/9/23 1:47 PM, Britton Kerin wrote:
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'
     use strict; use warnings;
     $| = 1;
     while ( 1 ) {
       my $rex = <>;
       chomp($rex);
       my $str = <>;
       if ( $str =~ m/$rex/ ) {
         # FIXME: Sadly this die argument doesn't show anywhere:
         defined($1) or die 'group $1 unexpectedly undefined';
         print length($1);
       }
       print "\n";
     }
   END_PERL
   )
}

It works great for my intended purpose (smarter word movement for
ble.sh), with the only issues being:

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?

Coprocs don't modify stderr, so if you write to stderr it will get to
wherever the calling shell has directed it.

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.
By default (there is a compile-time option to change it), the shell only
keeps track of a single coproc.

This means that it will reap the coproc when it dies, since it's a child
of the shell, but not unset any of the associated variables or ensure the
pipe file descriptors are closed in the parent.

3.  I don't really like seeing it as a job in job control.  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 is a job, since it's executed as if the command had been terminated
with `&'. If you don't want to see it, use `disown'; that's the general
mechanism for doing this.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/




reply via email to

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