Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #14714 > unrolled thread

Re: bash sockets: printf \x0a does TCP fragmentation

Started byBob Proulx <bob@proulx.com>
First post2018-10-11 15:35 -0600
Last post2018-10-11 15:35 -0600
Articles 1 — 1 participant

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: bash sockets: printf \x0a does TCP fragmentation Bob Proulx <bob@proulx.com> - 2018-10-11 15:35 -0600

#14714 — Re: bash sockets: printf \x0a does TCP fragmentation

FromBob Proulx <bob@proulx.com>
Date2018-10-11 15:35 -0600
SubjectRe: bash sockets: printf \x0a does TCP fragmentation
Message-ID<mailman.2042.1539293768.1284.bug-bash@gnu.org>
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 printf line buffers regardless, because it has always
done it that way since the beginning.  So for the moment at least
whether it is a tty or not doesn't matter to the bash printf.  Since
this is a lessor traveled corner of bash it hasn't been tripped over
much before.  And probably never discussed here.  However I think it
likely (I didn't check) that it does for the coreutils printf using
libc's default stdio buffering.  So it is good to know about
regardless.

I think it would make sense if bash's internal commands like printf
performed buffering the same way as the default libc does.  Then it
would behave the same as the rest and be less likely to cause
problems.  And it would have meant it would have worked by default in
your case.

Dirk Wetter wrote:
> Sorry, forget about my mail. In the actual file I was using there
> was a variable which I haven't quoted correctly. The PoC works as
> expected and it looks I have a solution.

The smallest of details can break the largest of programs. :-)

Good to hear you have things resolved and now working for you!

Bob

[toc] | [standalone]


Back to top | Article view | gnu.bash.bug


csiph-web