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

[guest271314]

>  This isn't "politics".  It's simply reality.

It is politics.

All human activity is political in nature.

> You're aware that dd, head, cat and most other commands are NOT part
of bash, right?

Yes. "most" is stretching it, though I understand what you are talking
about.

The system I am on has dd, head, cat exposed in the default shell, Bash.

I stated above I wrote the same code in C and C++. I compiled them both
with LLVM's clang and clang++ - not just gcc and g++. Then I compiled both
to WASM using WASI-SDK. So, that is portability. I use QuickJS more than I
use Node.js or Deno. I wrote Native Messaging hosts for those JavaScript
runtimes, too. As well as Bun, and txiki.js built from QuickJS source.

Again, if you think it is important to use tools that are defined on your
system you will need to write a Native Messaging host for your case. You
have to walk the walk and write the code and verify it works, yourself if
you are going to propose a version. Else what are you lobbying for? You
have not even verified the dd version you proposed works as you think it
might.

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

> On Sat, Jun 24, 2023 at 06:56:54PM -0700, guest271314 wrote:
> > > If you're content to require GNU tools, just say so.
> >
> > I have no idea what you are specifically talking about. Sounds like
> > politics.
>
> It's not politics.  It's technology.
>
> You're aware that dd, head, cat and most other commands are NOT part
> of bash, right?  They're provided by the operating system that the
> bash script runs on.
>
> On a (non-ancient) GNU/Linux system, those three commands are provided
> by the GNU coreutils project.
>
> The GNU implementation is just one of many possible implementations.
> On other systems, these tools are provided by a different set of authors,
> who have no connection to the GNU project.  They may work differently.
> POSIX defines a common baseline set of features that must be present, but
> each implementation adds its own unique set of features on top of that.
>
> So, when we discuss portability, there are at least two criteria involved:
>
>  * Which shell is running the script.
>  * What features are present in the external tools needed by the script.
>
> Your bash script might run on Linux, where head comes from GNU, or it
> might run on a commercial Unix system, where head comes from the operating
> system's manufacturer.  In both cases, the *shell* is the same (bash),
> but the underlying tool set is different.
>
> Your script might not work as you expect on a commercial Unix system,
> even if bash is installed on it.  This isn't "politics".  It's simply
> reality.
>
>