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


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

Re: bash sockets: printf \x0a does TCP fragmentation

Started bydirk+bash@testssl.sh
First post2018-09-22 11:50 +0200
Last post2018-09-22 11:50 +0200
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 dirk+bash@testssl.sh - 2018-09-22 11:50 +0200

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

Fromdirk+bash@testssl.sh
Date2018-09-22 11:50 +0200
SubjectRe: bash sockets: printf \x0a does TCP fragmentation
Message-ID<mailman.1130.1537609826.1284.bug-bash@gnu.org>

On 9/22/18 7:30 AM, Bob Proulx wrote:
> dirk+bash@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 should be a paragraph NOT COMMON where bash sockets
should rather belong to?

> More
> typically one would use a C program instead.  So it isn't surprising
> that you are finding interactions that are not well known.

Bob, my intention was not to discuss program languages and what is typical
with you or anybody else here.

>> printf -- "$data" >&5 2>/dev/null
> 
> Why is stderr discarded?  That is almost always bad because it
> discards any errors that might occur.  You probably shouldn't do this.>
> What happens if $data contains % format strings?  What happens if the
> format contains a sequence such as \c?  This looks problematic.  This
> is not a safe programming proctice.

I doubt you can judge on this by just looking at a single line
of code -- the project has > 18k LoC in bash.

Github is the place to discuss and do PRs for our project.

>> If there's a workaround, please let me know. (tried to add "%b" with no
>> effect). Otherwise I believe it's a bug.
> 
> You can re-block the output stream using other tools such as 'cat' or
> 'dd'.  Since you are concerned about block size then perhaps dd is the
> better of the two.
> 
>   | cat

cat has a problem with binary chars, right? And: see below.

> Or probably better:
> 
>   | dd status=none bs=1M
> 
> Or use whatever block size you wish.  The 'dd' program will read the
> input into its buffer and then output that block of data all in one
> write(2).  That seems to be what you are wanting.

We actually use dd to read from the socket. Of course we could use
writing to it as well -- at a certain point of time.

Still, a prerequisite would be that printf is the culprit and not
how bash + libs do sockets.

> P.S. You can possibly use the 'stdbuf' command to control the output
> buffering depending upon the program.
> 
>   info stdbuf

That could be an option, thanks. Need to check though whether

a) it doesn't fragment then -- not sure while reading it
b) it's per default available on every platform supported by testssl.sh.


Cheers, Dirk

[toc] | [standalone]


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


csiph-web