Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #16233
| 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> |
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
Re: Proposed new feature for bash: unbuffered pipes Daniel Colascione <dancol@dancol.org> - 2020-04-23 17:15 -0700
csiph-web