From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3631 invoked by alias); 25 Apr 2013 22:19:39 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 17784 Received: (qmail 5326 invoked from network); 25 Apr 2013 22:19:21 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <130425151839.ZM17476@torch.brasslantern.com> Date: Thu, 25 Apr 2013 15:18:39 -0700 In-reply-to: <20130425193817.2f82b60c@pws-pc.ntlworld.com> Comments: In reply to Peter Stephenson "Re: precmd: write error: interrupted" (Apr 25, 7:38pm) References: <130425111646.ZM17258@torch.brasslantern.com> <20130425193817.2f82b60c@pws-pc.ntlworld.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-users@zsh.org Subject: Re: precmd: write error: interrupted MIME-version: 1.0 Content-type: text/plain; charset=us-ascii 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 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.