On 9/25/18 8:25 AM, Greg Wooledge wrote:
> 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+b...@testssl.sh wrote:
>>>> On 9/22/18 7:30 AM, Bob Proulx wrote:
>>>>> dirk+b...@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.
Yes, bash does line buffering and provides a buffer for stdout and
stderr. This has been noted here previously and isn't specific to
printf or echo.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
