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
pgpN2rLLzteW9.pgp
Description: PGP signature
