Dirk Wetter wrote:
> PS + @Bob: fd 5 is not a tty in the program -- but interactively in
> this PoC you want to make sure it is not taken yet.
Understood. I originally mentioned the isatty() thing because that is
how libc decides to line buffer or not. But Chet has confirmed that
bash's internal
On 10/11/18 12:53 PM, Dirk Wetter wrote:
> This all -- including cat -- sounded reasonable. But it seems using sockets
> the internal printf
> as opposed to the one from coreutils is still causing fragmentation other
> than expected with
> strace PoC:
Bash line-buffers stdout, so newlines caus
On 11.10.18 18:53, Dirk Wetter wrote:
> bash 0$ exec 5<>/dev/tcp/81.169.199.25/443
> bash 0$ printf
> '\x16\x03\x01\x02\x00\x01\x00\x01\xfc\x03\x03\x54\x51\x1e\x7a\xde\xad\xbe\xef\x31\x33\x07\x00\x00\x00\x00\x00\xcf\xbd\x39\x04\xcc\x16\x0b\x85\x03\x90\x9f\x77\x04\x33\xd4\xde\x20\x44\xb8\x92\x56\
On 23.09.18 20:29, Bob Proulx wrote:
> Robert Elz wrote:
> $ { command printf "one\n"; sleep 1; command printf "two\n" ;} | strace -v
> -o /tmp/dd.strace.out -e write,read dd status=none ibs=1M obs=1M ; head
> /tmp/*.strace.out
> one
> two
> ...
> read(0, "one\n", 1048576)
On 10/10/18 6:52 PM, Bob Proulx wrote:
> Chet Ramey wrote:
>> b...@feusi.co wrote:
>>> The thing I noticed is that when setting a variable and then running the
>>> command "time", bash reports "command not found". For example, the
>>> command:
>>>
>>> TEST=1 time ls
>>>
>>> Results in "bash: time:
