Path: csiph.com!fu-berlin.de!usenet.stanford.edu!not-for-mail From: Greg Wooledge Newsgroups: gnu.bash.bug Subject: Re: bash sockets: printf \x0a does TCP fragmentation Date: Tue, 25 Sep 2018 08:25:41 -0400 Lines: 40 Approved: bug-bash@gnu.org Message-ID: References: <20180921231101307758654@bob.proulx.com> <714e1ba0-0052-2f2b-676d-778f2b7129c1@testssl.sh> <20180924130533.4ufaxypoelta6f7n@eeg.ccf.org> <5BAA26C6.10906@tlinx.org> NNTP-Posting-Host: lists.gnu.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: usenet.stanford.edu 1537878350 3099 208.118.235.17 (25 Sep 2018 12:25:50 GMT) X-Complaints-To: action@cs.stanford.edu To: bug-bash@gnu.org Envelope-to: bug-bash@gnu.org Mail-Followup-To: bug-bash@gnu.org Content-Disposition: inline In-Reply-To: <5BAA26C6.10906@tlinx.org> User-Agent: NeoMutt/20170113 (1.7.2) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 139.137.100.1 X-BeenThere: bug-bash@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Bug reports for the GNU Bourne Again SHell List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Xref: csiph.com gnu.bash.bug:14658 On Tue, Sep 25, 2018 at 05:15:02AM -0700, L A Walsh wrote: > On 9/24/2018 6:05 AM, Greg Wooledge wrote: > > On Sat, Sep 22, 2018 at 11:50:17AM +0200, dirk+bash@testssl.sh wrote: > > > On 9/22/18 7:30 AM, Bob Proulx wrote: > > > > dirk+bash@testssl.sh wrote: > > > > > printf -- "$data" >&5 2>/dev/null > > > > What happens if $data contains % format strings? What happens if the > > > > format contains a sequence such as \c? This looks problematic. This > > > > is not a safe programming proctice. > > > > Looking ONLY at this one line, there is an obvious bug, which Bob has > > pointed out. It should be > > > > printf %s "$data" >&5 2>/dev/null > ---- > This brings to mind a consideration: > As %s says to print a string of data (presumably not > including a NUL byte), then what happens if "$data" is > a paragraph of text with embedded newlines. In that case, > it sounds like bash might break apart the single printf > output into smaller packets rather than transmitting the > entirety of "$data" in 1 write (presuming it is less than > the maximum data size for a network packet). Yes, I'm sure it does. In fact, bash's printf and echo builtins are already known to use multiple calls to write() even when sockets and newlines are not involved. For example (from ): $ perl -e 'print "a"x2000, "\n"' > foo $ strace -e write bash -c 'read -r foo < foo; echo "$foo"' >/dev/null write(1, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 1008) = 1008 write(1, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"..., 993) = 993 +++ exited with 0 +++ There is no guarantee that the entire payload will be sent with a single write() command. If you need that kind of low-level control, bash is not the right language for this project.