Robert Elz wrote:
> ps: f there was actually a desire to use dd to do re-buffering, the
> correct usage is not to use "bs=" (which simply does read write with
> a buffer that size) but "obs=" which reads (using ibs if needed, which it
> would not be here), copies to an output buffer and writes
Date:Sat, 22 Sep 2018 14:22:19 -0600
From:Bob Proulx
Message-ID: <20180922111950901701...@bob.proulx.com>
| Primarily a shell script is a command and control program. It is very
| good for that purpose. It is typically used for that purpose. That
| is the
I see that you have subscribed now. Awesome! If you and others would
be so kind as to list-reply instead of CC'ing me directly that would
be great. I read the replies on the mailing list.
dirk+b...@testssl.sh wrote:
> Bob Proulx wrote:
> > You are doing something that is quite unusual. You
Found via fuzzing (of `read -e') using AFL,
To reproduce:
In a shell with `emacs' readline mode, type:
~/
e.g.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/dualbus/src/gnu/bash/bash
[Thread
On 9/22/18 6:38 AM, 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 4:21 AM, dirk+b...@testssl.sh wrote:
>
>
> 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
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 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 particular) use? It doesn't seem to be the usual stdio
On 22.9. 12:50, dirk+b...@testssl.sh wrote:
cat has a problem with binary chars, right? And: see below.
No, it just loops with read() and write(), it shouldn't touch any of the
bytes (except for cat -A and such). But it probably doesn't help in
coalescing the write blocks, it's likely to
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
12 matches
Mail list logo
