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

[guest271314]

I am not privy to the all of the gory details of Linux versus GNU/Core
Utilities other than the threads I have read on the subject-matter.
Politics. Now, I am a political animal, and a hardliner in that domain.
however, I started writing code as an exercise in engaging in human
activities that are not centered on politics - only yo be greeted with
politics in every realm of coding. Thus I have been banned by multiple
organizations in the specification, implementation, and general coding
domains for vetting spurious claims in documentations, standards, and
MVP's.

*buntu is essentially the same as or built from Debian, no?

When you suggest to stick with using dd, my reply is the same as I
previously stated: dd didn't work in this case.

It would help if you actually tried the code you suggested, so you can
reproduce the code I wrote and verify your own claims - more importantly,
so I can verify your claims.

I am not sure what you mean by "portable"? Use Chimera Linux. Busybox, and
not the default Bash shell shipped on *buntu distributions?

On Sat, Jun 24, 2023 at 4:47 PM Greg Wooledge <greg@wooledge.org> wrote:

> > 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.
>
>