Re: precmd: write error: interrupted

[Peter Stephenson <p.stephenson@samsung.com>]

On Thu, 25 Apr 2013 15:18:39 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Consider something like:
> 
>     x=({1..1000000}
>     print $x
> 
> If you can't ^C that print, you're potentially in a world of pain.  (It's
> already enough of a problem that you can't ^C the assignment itself.)

(I moved this bit to zsh-workers.)

OK, so what I'm missing is that while the shell code might whizz through
there could be long delays in the backend outputting it to the terminal,
during which the shell is still executing bin_print() (and that's still
true even given your later remarks about queueing).

> I'm pretty sure SIGWINCH is an outlier case here and we should focus on
> the question of when the shell SHOULD react to window size changes,
> rather trying to identify all the builtins that should NOT react.
> 
> For example, we might *always* queue the SIGWINCH signal except when the
> shell is blocked in zleread (or is about to, but hasn't yet, displayed
> the prompt if ZLE is not active).  Those probably don't cover all the
> cases, but you get the idea.

I can see that it's an infrequent operation that's there to fix things
up for the user, i.e. needs handling on the timescale of human reactions
rather than, say, the timescale of Unix processes.  So yes, it looks
plausible it could be handled differently.

I suppose if a foreground process is running, it has to be done as at
present: the process gets the signal and zsh handles it when it gets
back control (but my knowledge of process groups is a bit basic).

pws