[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-tar] I: tar-1.23 SIGPIPE regression
From: |
Dmitry V. Levin |
Subject: |
Re: [Bug-tar] I: tar-1.23 SIGPIPE regression |
Date: |
Fri, 19 Mar 2010 23:34:36 +0300 |
On Fri, Mar 19, 2010 at 02:04:13PM -0600, Eric Blake wrote:
> On 03/19/2010 01:51 PM, Dmitry V. Levin wrote:
> > On Fri, Mar 19, 2010 at 09:15:28PM +0200, Sergey Poznyakoff wrote:
> >> Dmitry V. Levin ha escrit:
> >>
> >>> introduces a regression:
> >>>
> >>> $ touch empty && tar -cf empty.tar empty && tar -tf empty.tar | :
> >>> tar: write error
> >>
> >> This is intended behavior: instead of silently ignoring the error,
> >> tar reports it.
> >
> > I understand that this change was intended, but I'm not sure that all
> > consequences of the change was taken into account. Now an innocent code
> > like "tar -tf $file |grep -q $pattern" produces misleading error output,
> > and the only way to avoid it is to suppress tar's stderr completely. :(
> > I hope the change was not designed to produce such a negative side effect.
>
> It may be worth asking the question of the Austin group (the folks in
> charge of POSIX) whether or not a process that detects write failures
> because of EPIPE (when sigpipe is ignored) falls into the normal
> category of being required to diagnose the error and exit with non-zero
> status, or whether it should be special-cased and cause silent exits.
> Tar is not the first project where people have complained about the
> level of verbosity present due to EPIPE write errors, but without any
> further blessing from the POSIX folks specifically stating that EPIPE
> should be special-cased, we are only following the POSIX rules as we
> understand them.
I think the issue you are talking about is not the same as what has
happened with tar-1.23 due to the deliberate abovementioned change of
SIGPIPE handler from SIG_DFL to SIG_IGN.
tar now ignores SIGPIPE no matter what the caller process decides on this
matter. I would understand if tar would treat EPIPE this way with the
inherited SIGPIPE signal state. But I have no idea why tar should report
these EPIPE errors in case when the caller process deliberately sets
SIGPIPE handler to SIG_DFL.
--
ldv
pgpiM5bdJ51uo.pgp
Description: PGP signature