From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13211 invoked by alias); 26 Apr 2013 08:43:06 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 31333 Received: (qmail 28448 invoked from network); 26 Apr 2013 08:42:54 -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=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at samsung.com does not designate permitted sender hosts) X-AuditID: cbfec7f5-b7fa36d000007f20-4c-517a3e095824 Date: Fri, 26 Apr 2013 09:42:48 +0100 From: Peter Stephenson To: Zsh Hackers' List Subject: Re: precmd: write error: interrupted Message-id: <20130426094248.42674faa@pwslap01u.europe.root.pri> In-reply-to: <130425151839.ZM17476@torch.brasslantern.com> References: <130425111646.ZM17258@torch.brasslantern.com> <20130425193817.2f82b60c@pws-pc.ntlworld.com> <130425151839.ZM17476@torch.brasslantern.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuphluLIzCtJLcpLzFFi42I5/e/4ZV1Ou6pAg7sreCwONj9kcmD0WHXw A1MAYxSXTUpqTmZZapG+XQJXRvvW58wFa3gqdq57xtrA+ICzi5GTQ0LAROLvpi9sELaYxIV7 68FsIYGljBJ3usW6GLmA7OVMErOevGcGSbAIqEos+3gbrIhNwFBi6qbZjF2MHBwiAtoS7R/F QMLCAroSlx+dASvhFbCX+LdgF1grp4CVxNl7L1ggZu5glDhwbRM7SIJfQF/i6t9PTBBH2EvM vHKGEaJZUOLH5HssIDazgJbE5m1NrBC2vMTmNW+ZJzAKzEJSNgtJ2SwkZQsYmVcxiqaWJhcU J6XnGukVJ+YWl+al6yXn525ihITg1x2MS49ZHWIU4GBU4uF1dKgMFGJNLCuuzD3EKMHBrCTC e3UGUIg3JbGyKrUoP76oNCe1+BAjEwenVANjY3RgsX6eWLhc17tvok5vtiZVmKp4Vf7Zucuy krWhssv9WFTYqwtVXAsXnk1R3rZcko17VcAx2+DyEBv3H9YfjbdcSef2+szwu2FD1kKxbEf1 pNVlCS+b1mX+Lzq8y7eIaZawyrHuXXy1a6Quc8/InPXvwOppT9Yn7Nt/mVco2zZ225kUDVcl luKMREMt5qLiRAACKwo4HwIAAA== On Thu, 25 Apr 2013 15:18:39 -0700 Bart Schaefer 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