On 7/18/11 10:46 AM, Steven W. Orr wrote:
> On 7/18/2011 10:14 AM, Ralph Corderoy wrote:
>> Hi,
>>
>> (I'm not subscribed to the list so please keep me CC'd.)
>>
>> Consider
>>
>> printf 'foo bar\n'>/dev/udp/localhost/4242
>>
>> with bash's printf built-in, it works fine. One packet is sent.
>> However, make that two lines
>>
>> printf 'foo\nbar\n'>/dev/udp/localhost/4242
>>
>> and two packets are sent, one per line. If the aim is to send a string
>> of data in one packet this causes problems.
>>
>> Using /usr/bin/printf from coreutils gives one write(2), so that's a
>> possible workaround.
>>
>> Is this happening because the built-in printf is using putchar(3) in the
>> PC() macro and stdio thinks file descriptor 1 is still to a tty so it's
>> persisting in line buffering? It would seem nicer if fewer write(2)s
>> were done when stdout isn't a tty, and not just for UDP use.
>>
>> Cheers, Ralph.
>
> Ooh! Can I try to answer this one?!
>
> Bash is always running in unbuffered mode, so every time a line is written,
> it automatically gets flushed. So... The only way to write in fully
> buffered mode with control over when things get flushed is to do it from a
> program that is not a bash script. So, yes. You need to do something
> outside of bash to get your output to the device.
Almost exactly right, except replace "unbuffered" with "line-buffered
output". Bash uses stdio and sets stdout and stderr to line-buffered.
The advantage of fully-buffered mode shows itself when writing large
amounts of data, which the shell does not do very often. The advantage
of line-buffered mode is better response.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
