Bug#31521: dpkg: dpkg dying in eterm

[Klaus Weide <kweide@tezcat.com>]

On Mon, 1 Mar 1999, Ian Jackson wrote:
[ order changed ]
> Klaus Weide writes ("Bug#31521: dpkg: dpkg dying in eterm"):
> > Is there something that support the claim that it is a bug if program A
> > fork/execs program B with SIGPIPE ignored?  For example some Unix specs,
> > or a Debian policy doc?
> 
> How about ANSI C ?

You are answering my question with a question, I'm not sure what to make
of it.  I don't have an ANSI C spec around - are you saying that yes,
ANSI C says it is a bug if program A fork/execs program B with SIGPIPE
ignored?   (Seems unlikely to me, that's why I'm asking more specifically
again.)

> > Pardon me, but it seems to me that if dpkg needs SIGPIPE non-ignored
> > to function properly, then it is up to dpkg to make it so.  Which
> > should be very simple to do.  Or is there ever a reason to honor a
> > parent process's SIG_IGN for SIGPIPE?
> 
> There might be.  The main point is that a program is entitled to
> assume that all signal handlers start in the default state.

Eterm is not the only program that behaves that way - the same has
been reported against lynx.  I suspect there are other programs that
ingnore SIGPIPE for their own purposes, and don't bother to explicitly
set it back to default before spawning children.

Now whether it is right or not in some sense that "a program is
entitled to assume..." - does it make sense for a program that *depends*
on that assumption for correct functioning, once it is know that the
assumption isn't always true, to fail in an obscure way?

As you can guess, my answer would be "no".  If the most important
objective is to have the program work for the end user in as many
situations as possible, it should stop making the assumption (unless
there are practical reasons against it).  If it is for some reason
regarded more important to teach other programs the errors of their
ways, dpkg should refuse to run with a message indicating why, instead
of risking foreseeable failure with obscure messages further down the
road.

    Klaus