From 38878b19333ba0dc950db9a55c52a3bcbd09c9b2 Mon Sep 17 00:00:00 2001 From: Tomi Ollila Date: Wed, 22 May 2013 10:50:46 +0300 Subject: [PATCH] Re: [RFC PATCH 1/1] add --stderr option --- 24/fb643f4473da27a6af78603b3ff3fc4c55c03e | 94 +++++++++++++++++++++++ 1 file changed, 94 insertions(+) create mode 100644 24/fb643f4473da27a6af78603b3ff3fc4c55c03e diff --git a/24/fb643f4473da27a6af78603b3ff3fc4c55c03e b/24/fb643f4473da27a6af78603b3ff3fc4c55c03e new file mode 100644 index 000000000..ecf158c11 --- /dev/null +++ b/24/fb643f4473da27a6af78603b3ff3fc4c55c03e @@ -0,0 +1,94 @@ +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 C5A4C431FBF + for ; 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 ; + 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 ; 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 +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~ +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." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-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 +>> 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... :) + + +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 + + +> +> Justus + +Tomi -- 2.26.2