Re: questions about coproc

[alex xmb ratchev]

On Tue, Mar 14, 2023, 3:55 PM Chet Ramey <chet.ramey@case.edu> wrote:

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

i could swear ' 0 1 2 ' from docs ... oh well

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

thats a great solution thxx

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