Re: [RFC PATCH 1/1] add --stderr option

[Tomi Ollila <tomi.ollila@iki.fi>]

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