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 _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
