Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #16233

Re: Proposed new feature for bash: unbuffered pipes

From Daniel Colascione <dancol@dancol.org>
Newsgroups gnu.bash.bug
Subject Re: Proposed new feature for bash: unbuffered pipes
Date 2020-04-23 17:15 -0700
Message-ID <mailman.1060.1587687374.3066.bug-bash@gnu.org> (permalink)
References <87blnhvkki.fsf@hobgoblin.ariadne.com> <7f4f4dcb-a5be-9a5b-aa51-fddf285dbbf2@dancol.org>

Show all headers | View raw


On 4/23/20 4:39 PM, Dale R. Worley wrote:
> Andreas Schwab <schwab@linux-m68k.org> writes:
>> See stdbuf(1).
> 
> The limitation(s) of stdbuf are:  It can only be applied to the standard
> I/O streams.  It doesn't affect statically-linked executables.  It only
> applies to a single executable, so if the command is a shell function or
> script, or creates subprocesses, it doesn't affect them.

If you want to define an environment variable for affecting stdout 
buffering, you can. (Good luck getting any libc to implement the support 
you're imagining: libc authors are *very* conservative about 
everything.) But whether or not you have this environment variable, you 
don't need special bash syntax to set it: you can just prefix the 
command you want with an environment variable assignment. I don't think 
the need you're discussing is widespread enough to warrant further 
complicating shell syntax.

A much simpler option might be just convincing libc people to make 
line-buffering the default whether isatty or not. Machines are very fast 
these days, and any program that _knows_ it's emitting non-line-oriented 
data can opt into full buffering.

Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Re: Proposed new feature for bash: unbuffered pipes Daniel Colascione <dancol@dancol.org> - 2020-04-23 17:15 -0700

csiph-web