Re: cpio terminates prematurely if its output is piped through head

[Bob Proulx]

Elmar Stellnberger wrote:
> cpio terminates prematurely if its output is piped through head:
> using cpio-2.9-75.45

Bugs in cpio should be reported to bug-cpio.  But you have contacted
the bug-coreutils list instead.  We don't know much about cpio here.
The bug reporting address for most programs is documented in the
manual and in the output from --help.

This is the right place to talk about 'head' however.

> cpio terminates prematurely if its output is piped through head:

Sure.  That is what it is supposed to be doing.  The 'head' program
prints the first few lines of input to the output and then
terminates.  It is a general purpose utility that is designed to work
with any program that produces data streams.

> cpio -idv './usr/include/*' 'usr/include/*' <$a 2>&1
> ... fully unpacks the archive $a

The 'cpio' command runs to completion.

> cpio -idv './usr/include/*' 'usr/include/*' <$a 2>&1 | head
> ... unpacks apparently non-deterministically just some but not all files
> of arcive $a

The 'cpio' command is terminated before it has run to completion.

The 'cpio' command has the standard error output redirected into the
'head' command's standard input.  The 'cpio' command has been given
the -v (verbose) option to print the file name to stderr.  The 'head'
command prints the first ten lines of input to the output.  After
having done that the 'head' command exits.  This causes a cascade of
program terminations as they are notified that they should exit.
Their output is no longer needed.  The 'cpio' command is the next
program to potentially be notified that it should exit.  The next
verbose output write of a filename from 'cpio' to the output pipe into
the now terminated 'head' command will cause it to receive a signal
telling it to exit.  The exact timing of this signal depends upon
several factors and accounts for the differences you are seeing in
different runs of the pipeline.  If there isn't any more output then
no signal is generated and the command will run to its own
termination.

> very strange!!

Actually no.  This is perfectly expected.  If you want the archive to
be fully unpacked then do not pipe the file list output through 'head'
to avoid having it terminated after only the first few files are
displayed.

>   In general a program should not be influenced by the fact how its
> output is used (whether piped to head or outputted directly). Most
> likely cpio just does not handle some error condition (output file
> descriptor closed by other party). However then it is perhaps a bug
> of head, because head should not disrupt its pipe antecessors by
> closing its file descriptor prematurely.

I am sorry but this is completely incorrect.  The Unix tradition
favors making as many programs as possible "filters" which process
text streams from input to output.  The design of the system relies
upon this behavior.

Consider the 'yes' program.  It produces an infinite number of strings
to its output.

  $ yes | head
  y
  y
  y
  y
  y
  y
  y
  y
  y
  y

If 'yes' did not terminate when the 'head' program terminated then it
would run forever.

Bob