[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Proposed new feature for bash: unbuffered pipes

From: Chet Ramey
Subject: Re: Proposed new feature for bash: unbuffered pipes
Date: Fri, 24 Apr 2020 14:04:22 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 4/22/20 9:31 PM, Dale R. Worley wrote:
> The crux of the problem, IMHO, is to look at it from the right angle:

I'm not going to add this to bash.

It's a bad idea to add a feature that will perpetually require a user to
patch glibc (!), and that will never be added to any mainline glibc
distribution. That results in a testing and maintenance burden.

Of course, relying on mods to glibc brings its own set of problems: not
all the world, and certainly not all the systems bash runs on, use glibc.
Not even all Linux systems use glibc. So relying on glibc-specific changes
to stdio is not portable or sustainable.

Even on systems that use glibc, and those whose owners are willing to patch
and build from source, the stdio-specific nature of the proposal leaves out
those programs that just don't use stdio. That's where you'd have to modify
the kernel, and that's unlikely to happen.

As has already been mentioned, stdbuf seems to address at least some of the
requirements here, without requiring changes to bash or to applications. It
has weaknesses of its own, I know, but it's a solution that exists today
and is at least somewhat portable.

Thanks for the proposal, and for stepping up and doing a sample
implementation, but I'm not accepting it.


``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    address@hidden    http://tiswww.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]