RE: PATCH: that execution stuff

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Andrej Borsenkow wrote:

> > Andrej Borsenkow wrote:
> >
> > > > I don't need to point out that `while true; do gzip ...; done' is not
> > > > expected to be ^C'able again, do I? Maybe we should document this?
> > > > (Together with the ^Z/fg/^C-trick?)
> > >
> > > It does not work. I can suspend *and* kill 'while true; do gzcat
> > -f; done'. But
> > > after I suspend and resume it, I can neither kill nor suspend it again.
> >
> > Hm, it worked for me with `zcat ... >/dev/null'. But this patch might
> > also have an effect on this (because of this sub-shell-pgrp thing).
> 
> Yes, now it works as described. No way to kill loop with gzcat before ^Z; ant
> two ^C's after that (I forgot, are two ^C's expected? Or was it supposed to be
> only one?).

Uff. That feels good ;-) And, yes, the two ^C's are expected -- one
for the gzcat which doesn't give us any information and the second one 
to kill the sub-shell. If the first gzcat in the loop has finished you 
need only one -- the second one ;-)

> In any case, as long as it is documented, it is far better as csh or ksh here.
> And thinking more about it - the only clean way to implement job control that
> works in any case is to start "guard zsh" for every pipeline (and run every
> pipeline in seperate process group). This is probably too much. It could be
> optimised if we are sure pipeline never executes external commands ... no idea
> how hard it is.

Extremly hard. To be exact: almost impossible because we might have a
list that first defines a function and then calls a command that once
looked like an external command but after that definition calls the
function. And other nasty things like that.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx