/usr/bin/script eating 100% cpu with portupgrade and xargs

[Chris Torek]

On Sep 18, 2011 11:25 AM, "Kostik Belousov" <kostikbel at gmail.com> wrote:
> Please note that interpreting the receiving of 0 bytes on the terminal
> as EOF is only a convention. If done absolutely properly, script shall
> not interpret zero-byte read as EOF. Might be, the reasonable thing to
> do would be to only look at the stdin once in a second after receiving
> zero-bytes, and switching it back to normal mode if something is read.

The other obvious alternative is to test for underlying file type, and
distinguish between "EOF is forever" (ordinary pipes and sockets, some
but not all block devices, etc) and "other".  In fact, the "EOF is
only temporary" mode introduced in the original change might
reasonably be limited to character devices only, for the purposes to
which script is put.

The delay method has significant merit in terms of simplicity, of
course: it avoids special-casing.  To truly fix the problem, though,
you would need something different in terms of a kernel interface: a
message from the master side of the pty saying "slave side has done a
read(n)" (where n is some integer), so that the program running the
pty can issue a corresponding read(n) on a buffer, to forward the
results back through the pty later.  Without this, the "script"
program erroneously translates one "EOF as signaled by read returning
0" into multiple "EOF on pty" signals.  Adding a delay simply changes
this from "as many as script can stuff down the pty at maximum CPU
rate" to "one a second".  Thus, if I were fixing this, I would lean
towards "EOF is just a temporary signal" being applied only to
character devices, and/or perhaps having a command-line flag to force
one mode or the other (with the default being "EOF is permanent on
everything except character devices").

Chris