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