Re: optimizing configure with resident sub-processes?

[Eric Siegerman]

On Mon, Jun 18, 2001 at 10:25:14PM +0200, Lars J. Aas wrote:
>   echo "dirname:$0" >$sed_in_fd
>   read basename <$sed_out_fd

This is pretty fragile, unless you write the subprocess code in C
(or maybe Perl) and ensure that it's completely unbuffered.

On many (most?) systems, if sed's output is to a pipe (or file,
or anything else other than a terminal), it's buffered at the
stdio level, making the output lag significantly behind the
input.  Worse, the output will be written whenever the buffer
fills up, which is not likely to be on a line boundary.

Here's a demonstration, on a Solaris X.7 system (where X is
whichever number Sun's marketing department is using this week
:-)  I've shown what I typed using a fictional "> " prompt that
I added after the fact:

        $ sed 's/a/a/' | cat -u
        > aaa
        > bbb
        > ccc
        > <EOT>
        aaa
        bbb
        ccc
        $

"cat -u" is not at fault in the above.  Proof:
        $ cat -u | cat -u
        > aaa
        aaa
        > bbb
        bbb
        > ccc
        ccc
        <EOT>
        $

Worse yet, in at least some sed's, the output stream lags a line
behind the input even at the application level; thus, playing
games with PTYs etc. to make the output "look like" a terminal is
not guaranteed to solve the problem.  Here's an interactive
version of the above:
        $ sed 's/a/a/'
        > aaa
        > bbb
        aaa
        > ccc
        bbb
        > <EOT>
        ccc
        $

To be truly robust, I'd want to label each command and response
with some unique id, and have the client (ie. configure) verify
the response's id.  Starts to sound like more effort than it's
worth...

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)