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

[guest271314]

> Nobody is talking about "politics" here.

I think we are talking politics re "portable".

Your example is not the code I am running. I think for you to establish
veracity re head use in this case you need to run the code I am running,
which you can do on Debian.

When I was experimenting the past week with using built-ins as a way to run
arbitrary shell scripts I experimented with tail and head, and was able to
read one byte at a time. That's why I recollected the -c, --bytes=[-]NUM
option.

> There are systems that aren't GNU/Linux.  Mac OS X, FreeBSD, OpenBSD,
Solaris, AIX, etc.  "Portable" means the code should work on all of these,
and more.

This particular question was relevant only for a Bash Native Messaging
host. A task I have been asking about and working on for years now.

I have mentioned several times now, and linked thereto, in this email
thread I wrote the same algorithm in C, C++, Python, JavaScript (QuickJS;
txiki.js; Deno; Node.js; Bun) and now Bash. Notice I had to write fice (5)
different versions for different JavaScript runtimes alone. Fix Python
implementation publish by GoogleChrome extensions samples that still uses
deprecated Python 2 and MDN For the idea of a universal executable there is
WASI/WebAssembly; I compiled the C source code, and later C++ source code,
of the same basic algorithm to WASM using WSAI-SDK that you can run with
wasmtime, or wasm3, or whatever WASM runtim you want (there are many for
each architecture; hell even Linux itself has been compiled to WASM using
buildroot, etc.), adjusted for language-specific artifacts, for
portability. I think you should re-read the links I have posted in this
thread, carefully.

It was non-trivial to figure out how to do this in Bash. I've asked, I
don't know, a half-dozen open questions re this requirement of mines over
the past several years, getting close at each step, yet nobody has yet
posted a working solution that I can reproduce. To be frank, nor have you
with your dd suggestion. The other suggestion with od did help.

I welcome PR's. That the point of
https://github.com/guest271314/NativeMessagingHosts.

Thanks, again.



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

> On Sat, Jun 24, 2023 at 05:06:23PM -0700, guest271314 wrote:
> > 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.
>
> Nobody is talking about "politics" here.
>
> > 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.
>
> unicorn:~$ seq 1865 | { head -n1; cat; }
> 1
>
> 1861
> 1862
> 1863
> 1864
> 1865
> unicorn:~$ seq 1865 | { dd bs=2 count=1 2>/dev/null; cat; }
> 1
> 2
> 3
> 4
> [...]
>
> > I am not sure what you mean by "portable"? Use Chimera Linux. Busybox,
> and
> > not the default Bash shell shipped on *buntu distributions?
>
> There are systems that aren't GNU/Linux.  Mac OS X, FreeBSD, OpenBSD,
> Solaris, AIX, etc.  "Portable" means the code should work on all of these,
> and more.
>
>