Subject: bin/5848: poor pipe behavior in sh
To: None <email@example.com>
From: David Holland <firstname.lastname@example.org>
Date: 07/24/1998 14:05:26
>Synopsis: sh makes poor assumptions about pipe buffer sizes
>Responsible: bin-bug-people (Utility Bug People)
>Arrival-Date: Sat Jul 25 20:35:00 1998
>Originator: David A. Holland <email@example.com>
- David A. Holland | VINO project home page:
firstname.lastname@example.org | http://www.eecs.harvard.edu/vino
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.