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

Groups > gnu.bash.bug > #14644 > unrolled thread

Re: bash sockets: printf \x0a does TCP fragmentation

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: bash sockets: printf \x0a does TCP fragmentation Chet Ramey <chet.ramey@case.edu> - 2018-09-23 14:23 -0400

#14644 — Re: bash sockets: printf \x0a does TCP fragmentation

On 9/22/18 6:49 AM, dirk+bash@testssl.sh wrote:
> 
> 
> On 9/22/18 12:38 PM, Ilkka Virta wrote:
>> On 22.9. 02:34, Chet Ramey wrote:
>>> Newline? It's probably that stdout is line-buffered and the newline causes
>>> a flush, which results in a write(2).
>>
>> Mostly out of curiosity, what kind of buffering logic does Bash (or the builtin
>> printf in particular) use? It doesn't seem to be the usual stdio logic where you get
>> line-buffering if printing to a terminal and block buffering otherwise. I get a
>> distinct write per line even if the stdout of Bash itself is redirected to say
>> /dev/null or a pipe:
>>
>>  $ strace -etrace=write bash -c 'printf "foo\nbar\n"' > /dev/null
>>  write(1, "foo\n", 4)                    = 4
>>  write(1, "bar\n", 4)                    = 4
>>  +++ exited with 0 +++
> 
> Oh. But thanks anyway!
> 
> coreutils in fact does it in one shot as you indicated.

Then the change you need suggests itself:

env printf ...

or

(exec printf ...)

since the bash exec builtin doesn't execute builtin commands.

Chet

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

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web