RE: pws-22: killing the ZSH loops problem

["Andrej Borsenkow" <borsenkow.msk@sni.de>]

> }
> } > } We need it only if MONITOR is set
> } >
> } > Not true!  MONITOR only affects handling of ^Z, not of ^C.  We need to be
> } > able to properly interrupt such loops in any shell.
> }
> } Ahem ... yes. What about "only in interactive shells?"
>
> What about "kill -INT"?  What about a shell script that isn't interactive
> but that's running in the foreground?
>

The shell script running in foreground will get INT from tty because it is in
TTY group and can do anything with it. The same, if I do kill -INT. The problem
only ever happens with loops started as part of shells with MIONITOR option set,
because it runs part of command (loop) in other process group as loop itself.
That prevents it from seeing this INT.

> } If don't miss something again: we have to fork only for the loop as whole.
>
> That's right, but the reason we don't do this now is so that parameter
> assignments inside the loop are visible after the loop terminates.  That
> doesn't work in most other shells.
>

As I understand, the last part of pipeline runs in current shell, and Sven's
suggestion was basically to run while ... done loop as <dummy command> | while
... loop. May be, I was wrong.

And another way is to run commands in the process group as shell and catch INT.
Is it even remotely possible?

> } ... so, it seems, execution time penalty is acceptable.  After all, you
> } don't use loops on every prompt.
>
> The execution time isn't as much at issue as is the process table space.
>

If it is needed (as I still believe) only for loops, started at PS1 when MONITOR
is set - it hardly happens too often. And having to kill your login shell to get
out of loop is not as nice