Re: sed bug on seekable stdin

[Bob Proulx]

Chuck Swiger wrote:
> Bob Proulx wrote:
> > How are I/O errors on stdin handled in this case?
> 
> A good question.

Does anyone know of a framework (such as /dev/full) for testing
program behavior in the presence of input I/O errors?

> I'd like to understand the motivation of this patch a little better; it is 
> to ensure something like consistent tape positioning if you attach sed's 
> stdin to a non-rewind tape drive (/dev/nst or similar)?  Or are you trying 
> to make sure that some utility earlier in the pipeline doesn't get an 
> unexpected SIGPIPE?

The original motivation was Eric's posting reporting a portability
problem and POSIX non-compliance issue.  Here is the original message
in the archive.

  http://lists.gnu.org/archive/html/bug-gnu-utils/2006-12/msg00059.html

Because sed has consumed input by reading ahead as part of its input
buffering that pre-cached input data is no longer available to later
commands in the pipeline.  The premise is that when the file is
seekable this problem is correctable and therefore sed should ensure
that later commands read the appropriate data from stdin by leaving
file's state at the point in the data stream that it left off.

For example on HP-UX (all versions that I tested) and I imagine
Solaris and others:

  $ printf "a\nb\n" > /tmp/file
  $ (sed -n 1q; cat) < /tmp/file
  b

While on GNU based systems no output is emitted.  (I peeked at Debian,
Ubuntu, RHEL and SLES.)  These systems violate POSIX and differ from
traditional Unix behavior.

Bob