On 9/23/18 8:26 PM, Chet Ramey wrote:
> 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
On 9/22/18 12:30 PM, Ilkka Virta wrote:
> The coreutils printf seems to output 'foo\nbar\n' as a single write, though
> (unless
> it goes to the terminal, so the usual stdio buffering), so you might be able
> to use
> that.
thx. Might be not that portable but we'll see.
> In any case, if a
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 buffering logic does Bash (or the
> builtin
> printf in
On 9/22/18 7:30 AM, Bob Proulx wrote:
> dirk+b...@testssl.sh wrote:
>> we discovered a strange phenomenon in the project testssl.sh:
>
> You are doing something that is quite unusual. You are using a shell
> script direction on a TCP socket. That isn't very common.
Do you think there
On 9/22/18 1:34 AM, Chet Ramey wrote:
> On 9/21/18 4:13 PM, dirk+b...@testssl.sh wrote:
>>
>> Hello there,
>>
>> we discovered a strange phenomenon in the project testssl.sh:
>>
>> After opening a TCP socket with a fd (here: 5), when writing to it,
>> it seems that
>>
>> printf -- "$data" >&5
Hello there,
we discovered a strange phenomenon in the project testssl.sh:
After opening a TCP socket with a fd (here: 5), when writing to it,
it seems that
printf -- "$data" >&5 2>/dev/null
does not do what it is intended. "$data" is a ClientHello like
