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

[guest271314]

I understand all of that.

> Just state up front that the script requires bash, and let your users
bear the responsibility for installing bash.

That is abundantly clear here [NativeMessagingHosts](
https://github.com/guest271314/NativeMessagingHosts). If you don't think
so, file an issue and/or PR.

I don't know how many times I have already stated in this thread that I
wrote the same algorithm in different programming languages. I'll list the
discrete version of the same algorithm here, again

- Python
- C
- C++
- QuickJS
- txiki.js
- Node.js
- Deno
- Bun
- WebAssembly/WASI
- Bash

For each of the JavaScript version I just used the executable itself; no
package manager involved, only tip-of-tree download. Or in the case of
QuickJS and txiki.js, built using gcc or clang. node and deno executables
exist for all kinds of operating systems. And then there is WASM, where
wasmtime can be used on whatever kind of machine you are on. That's the
whole point of WebAssembly: a universal executable.

Users in the field can choose whatever version they want to achieve the
same output. This Bash script is one option. If they want  shell script
that does the same as the Bash script then they can write it themselves, or
file a PR and we will work together making it so.

What I am reading is a philosophy, not an actual problem statement. You
folks have been heplpful on this board to solve the question I asked. I
think you are preaching to the choir re "portability" given the list of
programming languages I wrote the same algorithm in above.

On Sun, Jun 25, 2023 at 5:54 AM Greg Wooledge <greg@wooledge.org> wrote:

> On Sat, Jun 24, 2023 at 10:14:59PM -0700, guest271314 wrote:
> > Is this considered portable?
> >
> >   length=$(busybox dd iflag=fullblock bs=4 count=1 | busybox od -An -td4)
> >   message=$(busybox dd iflag=fullblock bs=$((length)) count=1)
>
> No, because most systems do not have busybox.
>
> You appear to have some fundamental disconnect with what we're saying.
> I don't know how to explain things in a way you will understand.
>
> If you're writing a script exclusively for your own private use, then
> you can stop when it "works", with the understanding that the script
> only works for you, right now, on the system you're currently using.
> It may break in the future, because you haven't really written it in
> a way that will ensure correct behavior on other systems (e.g. when
> you upgrade to the next release of your operating system).
>
> If that's what you want, then that's totally fine.
>
> But if you are writing a script that you intend other people to see, or
> even to use, then you need to understand portability.
>
> Portability means writing a script that can be run on *many* different
> systems, not just your own.
>
> There are two dimensions (for lack of a better word) to portability.
>
> The first dimension is writing for the correct shell interpreter.  In
> almost all situations there is a decision between two different shells:
> sh or bash.
>
> If you use bash-specific features like read -N then you are writing for
> bash.  The shebang needs to reflect that (#!/bin/bash or
> #!/usr/bin/env bash).
>
> If you choose to go the other direction, and write for sh, then you need
> to *avoid* all bash-specific features.  You need to write for the common
> denominator specified by POSIX for the shell language.  No arrays, no
> local variables in functions, no here strings, no [[ keyword, no extended
> globs, and so on.  Then you can use the #!/bin/sh shebang.
>
> Personally, I would stick with bash scripts.  Giving up arrays is so
> incredibly painful that it's seldom worthwhile for nontrivial scripts.
> Just state up front that the script requires bash, and let your users
> bear the responsibility for installing bash.  For most users, this is
> already done anyway.
>
> The second dimension is writing for the correct *operating system*.
> This dimension covers all of the external commands that your script
> uses.  On a GNU/Linux system, many of these external commands have
> extensions beyond the basic feature set specified by POSIX.  For example,
> GNU sed has a "-i" option to "edit a file in place" (really, it uses a
> temp file and replaces the original).  POSIX does not have this
> feature.  GNU grep has "-o" to write out only the part of the line
> which matches, rather than the whole line.  POSIX does not have this
> feature.  And so on, and so on.  There are *thousands* of these little
> extensions and creeping features.
>
> If you want your script to work on other operating systems, not just
> the one you're using, then you need to avoid those extensions.  Which
> means, first, you need to know what they are.  This is a lifelong
> journey, and you will probably miss a bunch of them the first few
> times you try to write a portable script.  That's to be expected.  Your
> users will report bugs when things don't work, and then you can learn
> from the bugs, and fix them, and make your scripts more portable over
> time.
>
> So, when we say things like "head -c4 using non-buffered input might not
> be portable", we're simply trying to warn you that your script is using
> one of these extensions, and that you might want to choose a different
> method, which *is* portable.  We're using our own experience to warn
> you of a potential issue.
>
>