Date:Sat, 22 Sep 2018 23:51:08 -0600
From:Bob Proulx
Message-ID: <20180922231240358868...@bob.proulx.com>
| Using the same buffer size
| for input and output is usually most efficient.
Yes, but as the objective seemed to be to make big packets, that is probably
n
On 9/22/18 6:49 AM, dirk+b...@testssl.sh wrote:
>
>
> On 9/22/18 12:38 PM, Ilkka Virta wrote:
>> 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 b
On 9/22/18 4:22 PM, Bob Proulx wrote:
> Note that I *did* provide you with a way to do what you wanted to do. :-)
>
> It was also noted in another message that the external standalone
> printf command line utility did buffer as you desired. That seems
> another very good solution too. Simply us
Robert Elz wrote:
> Bob Proulx wrote:
> | Using the same buffer size
> | for input and output is usually most efficient.
>
> Yes, but as the objective seemed to be to make big packets, that is probably
> not as important.
The original complaint concerned flushing a data blob content upon
ever
Chet Ramey wrote:
> Bob Proulx wrote:
> > It was also noted in another message that the external standalone
> > printf command line utility did buffer as you desired. That seems
> > another very good solution too. Simply use "command printf ..." to
> > force using the external version.
>
> This
Chet Ramey wrote:
> It's that bash sets stdout and stderr to be line-buffered, not anything
> printf-specific.
Shouldn't bash set stdout buffering based upon the output descriptor
being a tty or not the same as other libc stdio behavior?
Bob
On 9/20/18 6:37 PM, Grisha Levit wrote:
> I was testing out this new feature and I can't figure out how to handle
> certain characters in subscripts when the option is on. Without the
> option,
> it is possible to escape the `$' in the subscript to achieve the desired
> result but obviously that d
On 9/23/18 2:46 PM, Bob Proulx wrote:
> Chet Ramey wrote:
>> It's that bash sets stdout and stderr to be line-buffered, not anything
>> printf-specific.
>
> Shouldn't bash set stdout buffering based upon the output descriptor
> being a tty or not the same as other libc stdio behavior?
It's been s
