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

[Greg Wooledge]

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.