From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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