From 0e6eb5c395402d159f24d1ed74b3d3f6901cd070 Mon Sep 17 00:00:00 2001 From: Justus Winter <4winter@informatik.uni-hamburg.de> Date: Wed, 22 May 2013 13:15:25 +0200 Subject: [PATCH] Re: [RFC PATCH 1/1] add --stderr option --- 21/c6b7abb667c5eb33dd3b1852ac1445515280e7 | 131 ++++++++++++++++++++++ 1 file changed, 131 insertions(+) create mode 100644 21/c6b7abb667c5eb33dd3b1852ac1445515280e7 diff --git a/21/c6b7abb667c5eb33dd3b1852ac1445515280e7 b/21/c6b7abb667c5eb33dd3b1852ac1445515280e7 new file mode 100644 index 000000000..bac321a13 --- /dev/null +++ b/21/c6b7abb667c5eb33dd3b1852ac1445515280e7 @@ -0,0 +1,131 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 14A7A431FC0 + for ; Wed, 22 May 2013 04:15:57 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0 +X-Spam-Level: +X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] + autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id 9CJBgpS+yqwt for ; + Wed, 22 May 2013 04:15:49 -0700 (PDT) +Received: from mail.cryptobitch.de (cryptobitch.de [88.198.7.68]) + (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id E06A7431FB6 + for ; Wed, 22 May 2013 04:15:48 -0700 (PDT) +Received: from mail.jade-hamburg.de (mail.jade-hamburg.de [85.183.11.228]) + (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) + (No client certificate requested) + by mail.cryptobitch.de (Postfix) with ESMTPSA id 06DCF62D1CE + for ; Wed, 22 May 2013 13:15:30 +0200 (CEST) +Received: by mail.jade-hamburg.de (Postfix, from userid 401) + id 3F712DF2A2; Wed, 22 May 2013 13:15:29 +0200 (CEST) +Received: from thinkbox.jade-hamburg.de (cryptobitch.de [88.198.7.68]) + (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) + (No client certificate requested) (Authenticated sender: teythoon) + by mail.jade-hamburg.de (Postfix) with ESMTPSA id 05DF3DF28B; + Wed, 22 May 2013 13:15:26 +0200 (CEST) +Received: from teythoon by thinkbox.jade-hamburg.de with local (Exim 4.80) + (envelope-from ) + id 1Uf70v-0005o5-RL; Wed, 22 May 2013 13:15:25 +0200 +Content-Type: text/plain; charset="utf-8" +MIME-Version: 1.0 +Content-Transfer-Encoding: quoted-printable +From: Justus Winter <4winter@informatik.uni-hamburg.de> +User-Agent: alot/0.3.4 +To: Tomi Ollila , notmuch@notmuchmail.org +References: <1369161750-12342-1-git-send-email-tomi.ollila@iki.fi> + <20130521195549.6550.53636@thinkbox.jade-hamburg.de> + +In-Reply-To: +Message-ID: <20130522111525.9218.25144@thinkbox.jade-hamburg.de> +Subject: Re: [RFC PATCH 1/1] add --stderr option +Date: Wed, 22 May 2013 13:15:25 +0200 +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Wed, 22 May 2013 11:15:57 -0000 + +Quoting Tomi Ollila (2013-05-22 09:50:46) +> On Tue, May 21 2013, Justus Winter <4winter@informatik.uni-hamburg.de> wr= +ote: +> = + +> > Quoting Tomi Ollila (2013-05-21 20:42:30) +> >> --- +> >> = + +> >> Note quickly written untested code (but compiles!), just to show an id= +ea... +> >> = + +> >> This implements (i hope) curl(1) --stderr option in notmuch(1): +> >> = + +> >> --stderr +> >> Redirect all writes to stderr to the specified file ins= +tead. If +> >> the file name is a plain '-', it is instead written to s= +tdout. +> >> = + +> >> This would be useful in emacs interface. +> > +> > Hm, shouldn't it be possible to bind a pipe(2) to stderr instead? I +> > mean in the process of running the notmuch binary (i.e. somewhere +> > along the lines of fork and exec)? +> = + +> Yes, if emacs(1) were smarter ;/ + +Uh >,< + +> > I've implemented this for alot, which does not use the binary but +> > directly calls into libnotmuch, but does so in a helper process. Said +> > helper has a pipe(2) on stderr and the alot process reads from it and +> > turns any line into a log message. +> = + +> It is unfortunate that you have to do that -- libnotmuch should not +> emit anything to stderr... We've briefly discussed what changes +> are needed to libnotmuch what could be done there but... :) +> = + +> +> Instead of running separate process you could have both ends of the +> pipe in same process and check after libnotmuch call whether there = + +> is data in the reading end of the pipe. I think pipe buffers like 4k +> of data. If you used socketpair(2) that buffers 100k of data by +> default in Linux systems. Still, using nonblocking fds are +> advisable if using this hack ;D +> + +Umm, no I don't see how that would work. I mean I'd have to dup(2) a +fd to 2, but that means not only libnotmuch will write stuff to it but +anything ever written to stderr by alot also ends up there. + +It is also a means of protecting alot against any fatal errors in +libnotmuch, like segfaults and stuff like this. I'm not sure if that's +changed, but libnotmuch used to call exit once in a while taking alot +with it. With a separate subprocess you can just log this and restart +the process and you don't ever lose any mail. + +But yes, it's kind of a hack. + +Justus -- 2.26.2