From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <tomi.ollila@iki.fi>
Received: from localhost (localhost [127.0.0.1])
	by olra.theworths.org (Postfix) with ESMTP id C5A4C431FBF
	for <notmuch@notmuchmail.org>; Wed, 22 May 2013 00:51:02 -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 xQerEs0mkee5 for <notmuch@notmuchmail.org>;
	Wed, 22 May 2013 00:50:54 -0700 (PDT)
Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])
	by olra.theworths.org (Postfix) with ESMTP id 719E7431FB6
	for <notmuch@notmuchmail.org>; Wed, 22 May 2013 00:50:54 -0700 (PDT)
Received: from guru.guru-group.fi (localhost [IPv6:::1])
	by guru.guru-group.fi (Postfix) with ESMTP id 7B1E41002C3;
	Wed, 22 May 2013 10:50:46 +0300 (EEST)
From: Tomi Ollila <tomi.ollila@iki.fi>
To: Justus Winter <4winter@informatik.uni-hamburg.de>, notmuch@notmuchmail.org
Subject: Re: [RFC PATCH 1/1] add --stderr option
In-Reply-To: <20130521195549.6550.53636@thinkbox.jade-hamburg.de>
References: <1369161750-12342-1-git-send-email-tomi.ollila@iki.fi>
	<20130521195549.6550.53636@thinkbox.jade-hamburg.de>
User-Agent: Notmuch/0.15.2+115~g12cf6af (http://notmuchmail.org) Emacs/24.3.1
	(x86_64-unknown-linux-gnu)
X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL
	$[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F
	!)g;OY^,BjTbr)Np:%c_o'jj,Z
Date: Wed, 22 May 2013 10:50:46 +0300
Message-ID: <m261yb4fmx.fsf@guru.guru-group.fi>
MIME-Version: 1.0
Content-Type: text/plain
X-BeenThere: notmuch@notmuchmail.org
X-Mailman-Version: 2.1.13
Precedence: list
List-Id: "Use and development of the notmuch mail system."
	<notmuch.notmuchmail.org>
List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
	<mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
List-Archive: <http://notmuchmail.org/pipermail/notmuch>
List-Post: <mailto:notmuch@notmuchmail.org>
List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
	<mailto:notmuch-request@notmuchmail.org?subject=subscribe>
X-List-Received-Date: Wed, 22 May 2013 07:51:02 -0000

On Tue, May 21 2013, Justus Winter <4winter@informatik.uni-hamburg.de> wrote:

> Quoting Tomi Ollila (2013-05-21 20:42:30)
>> ---
>> 
>> Note quickly written untested code (but compiles!), just to show an idea...
>> 
>> This implements (i hope) curl(1) --stderr option in notmuch(1):
>> 
>>        --stderr <file>
>>               Redirect  all writes to stderr to the specified file instead. If
>>               the file name is a plain '-', it is instead written to stdout.
>> 
>> 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 ;/

> 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... :)

<questionable advice>
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
</questionable advice>

>
> Justus

Tomi