Re: Help fixing NativeMessaging host: read 32-bit message length in native byte order

[Greg Wooledge]

> On Sat, Jun 24, 2023 at 4:27 PM Greg Wooledge <greg@wooledge.org> wrote:
> 
> > On Sat, Jun 24, 2023 at 03:32:10PM -0700, guest271314 wrote:
> > > #!/bin/bash
> > > getMessage() {
> > >   length=$(head -q -z --bytes=4 -| od -An -td4 -)
> > >   message=$(head -q -z --bytes=$((length)) -)
> > >   sendMessage "$message"
> > > }
> >
> > Does that actually work?  In my experience, head(1) reads a buffer
> > full of input, even if it's only going to print a single line.  But
> > maybe the GNU version acts differently when given the --bytes argument?
> > If so, either congratulations are in order on your detective work,
> > or else you got lucky.

On Sat, Jun 24, 2023 at 04:33:03PM -0700, guest271314 wrote:
> Yes, it works as expected.
> 
> Only took me a few years and thousands of manual tets to figure out.

As an illustration, here's what I'm talking about.  This is on Debian 12.

unicorn:~$ seq 1865 | { head -n1; cat; } 
1

1861
1862
1863
1864
1865

Naively, one might think that "head -n1" would consume the first line of
input, and then cat would show the remaining lines, beginning with "2".
What actually happens is head reads an entire buffer full of input (in
this case, it appears to consume 8 kB), finds the end of the first line
within that buffer, and then prints the single line it was asked to
print.  However, that whole buffer has been consumed now, and so "cat"
only gets the remaining few bytes.

But it appears that GNU head acts *differently* when given a byte-based
argument instead of a line-based one.

unicorn:~$ seq 1865 | { head -c2; cat; } 
1
2
3
4
5
6
[...]

I was not aware of this.  This is what allows your code to work with
head instead of dd.

I do not believe that this is portable.  I would not expect head to work
this way on other operating systems.  You really ought to stick with dd,
even if you're only targeting GNU systems, just to stay in good habits.