Path: csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From: Ilkka Virta <itvirta@iki.fi>
Newsgroups: gnu.bash.bug
Subject: Re: bash sockets: printf \x0a does TCP fragmentation
Date: Sat, 22 Sep 2018 13:38:06 +0300
Lines: 19
Approved: bug-bash@gnu.org
Message-ID: <mailman.1134.1537612691.1284.bug-bash@gnu.org>
References: <c6de6616-dda0-570d-de56-419e7676be8a@cbii-hh.de> <69b48113-bc58-e0c8-a551-03a7e72d88d4@case.edu>
NNTP-Posting-Host: lists.gnu.org
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: dirk+bash@testssl.sh, bug-bash@gnu.org
To: chet.ramey@case.edu
Envelope-to: bug-bash@gnu.org
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
In-Reply-To: <69b48113-bc58-e0c8-a551-03a7e72d88d4@case.edu>
Content-Language: en-US
Precedence: list
Xref: csiph.com gnu.bash.bug:14634

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 +++


-- 
Ilkka Virta / itvirta@iki.fi