From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3894 invoked by alias); 25 Apr 2013 18:16:58 -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: 17778 Received: (qmail 13689 invoked from network); 25 Apr 2013 18:16:55 -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: <130425111646.ZM17258@torch.brasslantern.com> Date: Thu, 25 Apr 2013 11:16:46 -0700 In-reply-to: Comments: In reply to "Yuri D'Elia" "precmd: write error: interrupted" (Apr 25, 6:47pm) References: 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, 6:47pm, Yuri D'Elia wrote: } } I still have the error, as I didn't find any way to silence it (braces } around print do not work?!). That's curious, but try using parentheses to force a fork and redirect the stderr of the subshell. } I have no idea which write is actually failing in that function (I } suppose it's some "fputs" in bin_print). strace should be able to show you what bytes are being written, which would narrow it down. } :(. I really wished I had dtrace here... On every host where I have dtrace, I wish I had strace. } What's happening is that the terminal is being resized immediately after } starting, and a SIGWINCH is emitted while the actual "precmd" write is } being done on stdout. The call is not restarted and the write fails. Yes, the zsh signal handler setup explicitly prevents system call restart whenever possible, so that (among other reasons) behavior from traps is consistent across operating systems. } 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. On the other hand we probably don't want to build a wrapper around the entire stdio library just to differentiate terminal writes. } 2) Why "precmd() { { print "HELLO" } >&- 2>&-; } doesn't suppress the } error in this case? It's not the same error. Try 2>/dev/null instead of 2>&- ... with the stderr closed, you're actually getting a second error from outside the braces, about not being able to write the first error from inside! torch% print -u99 "Hello" print: bad file number: -1 torch% { print -u99 "Hello" } 2>&- zsh: write error torch% { print -u99 "Hello" } 2>/dev/null torch%