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, [email protected] wrote: > > > On 9/22/18 7:30 AM, Bob Proulx wrote: > > > > [email protected] 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 <https://mywiki.wooledge.org/BashPitfalls#pf51>): $ 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.
