Dmitry Bogatov writes ("Re: Bug#841090: Why not just set signal handlers?"):
> [2016-11-26 17:22] Ian Jackson <ijack...@chiark.greenend.org.uk>
> > Any program with sufficiently careful error handling will break when
> > SIGPIPE is ignored.
>
> If it is careful enough, it can setup all handlers by itself.
Yes, but programs don't (eg, ls, interactive shells, etc., see below)
and are not required to.
> > Interactive shells with SIGPIPE ignored are a latent bug which I want
> > to flush out.
>
> Can you elaborate?
Just to give an example:
zealot:~> yes | true
zealot:~> echo "${PIPESTATUS[@]}"
141 0
zealot:~> debian_chroot='(nosigpipe)' perl -e '$SIG{PIPE}=IGNORE; exec @ARGV'
bash
(nosigpipe)zealot:~> yes | true
yes: standard output: Broken pipe
(nosigpipe)zealot:~> echo "${PIPESTATUS[@]}"
1 0
(nosigpipe)zealot:~>
Observe that in the 2nd case:
* a spurious message is produced on stderr
* `yes' calls exit(1) rather than dying due to a fatal SIGPIPE
> > > I just took time to explore dgit and discovered, that it does not work
> > > under dvtm or dtach (did not tested screen or tmux).
> >
> > Please file bugs against those programs.
>
> I am debian maintainer of dvtm, but I am not convinced yet that removing
> signal(SIGPIPE, SIG_IGN) would do more good then evil. Link to something
> like 'signal(SIGPIPE, SIG_IGN) considered harmful'?
I did look in SUSv3 (POSIX) for something that categorically states
that executing nonconsenting programs with SIGPIPE ignored is
forbidden. Unfortunately the language in SUSv3 is distressingly
vague. I would argue that the fact that
http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_04_03_01
describes SIG_DFL as "Signal-specific default action" means that this
is what an application is allowed to expect from the operating system.
(If as one application, you run another, you obviously need to play
the role of the operating system in that interface.)
> So far, it looks to me that you are artificially pushing your opinion on
> what other programs should or should not do. No offense.
It's certainly not just my opinion. This bug was fixed in Python and
GHC and xfce4-terminal already. The bug I filed against lightdm has
been fixed.
https://ghc.haskell.org/trac/ghc/ticket/4274
https://twistedmatrix.com/trac/ticket/4199
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733722
Here's a blog post from Colin Watson on the subject:
http://www.chiark.greenend.org.uk/~cjwatson/blog/python-sigpipe.html
Note that there is nothing wrong with setting SIGPIPE to SIG_IGN,
within your own program, or when executing programs that expect to be
run that way. It is often very convenient to do so, because in many
(particularly, concurrent) programs SIGPIPE is quite a nuisance.
The bug is in not resetting it after fork and before exec.
> Sure, I was able to find workarounds, but like when things just work,
> don't we?
Well certainly if this kind of thing is going to be common I should
probably make dgit print a warning and reset SIGPIPE itself.
Or maybe I'll write a patch for bash to print the same warning.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
