Subject: bin/5848: poor pipe behavior in sh
To: None <>
From: David Holland <>
List: netbsd-bugs
Date: 07/24/1998 14:05:26
>Number:         5848
>Category:       bin
>Synopsis:       sh makes poor assumptions about pipe buffer sizes
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Jul 25 20:35:00 1998
>Originator:     David A. Holland <>
   - David A. Holland             |    VINO project home page:    |
>Release:        1.3

	This problem appears in the 1.3 release source for sh, and
	appears to remain in -current.


	sh assumes a pipe can hold at least 4k, via the #define in
	redir.c that sets PIPESIZE to 4096.

	This assumption is not necessarily correct. 

	This value is only used to determine whether or not forking
	is needed when processing a << redirection. The upshot of 
	this is that under rare circumstances (`<<' is rare, and
	`<<' of large blocks is rarer, and worse, it doesn't always
	happen and I don't know why) the shell will mysteriously


	Build a kernel with 2K pipes (or build sh on a system with 2K
	pipes) and run the configure script from gnu binutils 2.8.2.


	At a minimum, the uses of PIPESIZE should be changed to

	Either that, or the logic should be changed to always fork.
	This depends on whether the formal definition of PIPE_BUF and
	the circumstances of the write guarantee that the shell won't
	block. I believe that they do not guarantee this, but it is
	a matter for standards lawyers to argue over.

	Note that PIPESIZE is also defined but not used in init.c.