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

[Justus Winter <4winter@informatik.uni-hamburg.de>]

Quoting Tomi Ollila (2013-05-22 09:50:46)
> 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 ;/

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

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