Re: precmd: write error: interrupted

[Bart Schaefer <schaefer@brasslantern.com>]

On Apr 25,  7:38pm, Peter Stephenson wrote:
} Subject: Re: precmd: write error: interrupted
}
} On Thu, 25 Apr 2013 11:16:46 -0700
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > } 1) SIGWINCH should either be masked or allow write to restart.
} > 
} > This requires some thought about the appropriate layer to handle this.
} > bin_print does already do some signal queuing when writing to internal
} > data structures (print -z, print -s), but that's deliberately isolated
} > to bin_print, whereas all sorts of other things might write to the
} > terminal -- including other error messages! -- so patching bin_print is
} > not covering all the bases.
} 
} Certainly true, but I'm hesitant to do nothing

I'm not suggesting doing nothing, just haven't decided yet what's the
right thing.

} Explicit user output via print and error messages via
} zsh's own error and warning functions are two cases that cover quite a
} lot.  If there's already signal queuing in print, is it up to snuff?

It's using queue_signals()/unqueue_signals() which of course queues
*all* signals.  I don't think we want to do that in the "ordinary" case,
it introduces side-effects like loops you can't interrupt with ctrl-C.

} Is there ever a good reason for allowing a single print to be
} interrupted at the point of output --- surely it's always going to do
} unhelpful things?

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 don't think we'd want to queue interrupts round all builtins,
} but could we mark those that produce output but otherwise return
} immediately with a flag in the builtin table and do some queueing in
} the builtin handler?

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.