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

[guest271314]

I just read something like that here
https://stackoverflow.com/questions/10067266/when-to-wrap-quotes-around-a-shell-variable
.

I don't see that as authorative. If an official documentation suggested
that the recommendation would have canonical authority.

Unlike Python, which automatically includes spaces for formatting in JSON
https://github.com/mdn/content/pull/23451, I don't think Bash adds
formatting spaces to JSON, where all data except for literal numbers in
enclosed in double quotes.

E.g.,

port.postMessage(1);

cat data.txt
1

port.postMessage({abc: 123});

cat data.txt
{"abc":123}

port.postMessage('test');

cat data.txt
"test"


The current code without double quotes is working as intended.

Can you create a case for processing JSON where not adding double quotes to
a Bash variable breaks the code? I welcome PR's, with explanation of why,
and how not doing so breaks the current implementation.

On Sat, Jun 24, 2023 at 5:04 PM dan b <tekvax@hotmail.com> wrote:

> As I understand it;
> Add quotes if the variable will contain either an empty value, contain
> spaces or whitespace, or special characters such as wildcards. Not double
> quoting strings with spaces often leads to the shell breaking apart a
> single into multiple arguments.
>
> In my case a had a username csv list while done read with
> “firstname.lastname”, and “first-initial-lastname” that may or may not have
> also been bound with white space or tabs as well.
> By not double quoting, the dots between the names were changing to spaces.
> The argument was wrapped in a sed statement to remove white space, so the
> firstlast name were concatenates together…. It took a great deal of time
> to find that mistake, because it did contain an “$(echo $line)” that I did
> quote around… it was a dumb mistake that took hours to find… :(
>
> Cheers,
> Dan
>
> --
> t e k v a x @ hotmail.com
> sent via mobile.
> +19059205138
>
> On Jun 24, 2023, at 19:22, guest271314 <guest271314@gmail.com> wrote:
>
> 
> Thanks. Can you explain why the double quoting of assigned variables is
> impotant?
>
> On Sat, Jun 24, 2023 at 3:59 PM dan b <tekvax@hotmail.com> wrote:
>
>> “Important safety tip #427” :)
>>
>> Remember to always double quote around assigned variables.
>> The life you save maybe your own…
>> I was just caught by this in a while done read csv file variable, because
>> I failed to double quote the data=“$line” assignment, the string contents
>> were getting changed in strange ways.
>>
>> length=“$(head -q -z --bytes=4 -| od -An -td4 -)“
>>
>> message=“$(head -q -z --bytes=$((length)) -)
>>  sendMessage "$message"
>> }“
>>
>>  Cheers,
>> Dan
>>
>> --
>> t e k v a x @ hotmail.com
>> sent via mobile.
>> +19059205138
>>
>> On Jun 24, 2023, at 18:32, guest271314 <guest271314@gmail.com> wrote:
>>
>> I finally figured this out with you folks' help.
>>
>> I substituted using head for read.
>>
>> Thank you so much!
>>
>> #!/bin/bash
>> set -x
>> #!/bin/bash
>> getMessage() {
>>  length=$(head -q -z --bytes=4 -| od -An -td4 -)
>>  message=$(head -q -z --bytes=$((length)) -)
>>  sendMessage "$message"
>> }
>> # https://stackoverflow.com/a/24777120
>> sendMessage() {
>>  message="$*"
>>  # Calculate the byte size of the string.
>>  # NOTE: This assumes that byte length is identical to the string length!
>>  # Do not use multibyte (unicode) characters, escape them instead, e.g.
>>  # message='"Some unicode character:\u1234"'
>>  messagelen=${#message}
>>  # Convert to an integer in native byte order.
>>  # If you see an error message in Chrome's stdout with
>>  # "Native Messaging host tried sending a message that is ... bytes
>> long.",
>>  # then just swap the order, i.e. messagelen1 <-> messagelen4 and
>>  # messagelen2 <-> messagelen3
>>  messagelen1=$(((messagelen) & 0xFF))
>>  messagelen2=$(((messagelen >> 8) & 0xFF))
>>  messagelen3=$(((messagelen >> 16) & 0xFF))
>>  messagelen4=$(((messagelen >> 24) & 0xFF))
>>  # Print the message byte length followed by the actual message.
>>  printf "$(printf '\\x%x\\x%x\\x%x\\x%x' \
>>    $messagelen1 $messagelen2 $messagelen3 $messagelen4)%s" "$message"
>> }
>>
>> main() {
>>  while true; do
>>    getMessage
>>  done
>> }
>>
>> main
>>
>>
>>
>> On Sat, Jun 24, 2023 at 8:21 AM Greg Wooledge <greg@wooledge.org> wrote:
>>
>> > On Sat, Jun 24, 2023 at 08:10:39AM -0700, guest271314 wrote:
>> >> So, in the end, you can use something like this.
>> >>
>> >>  length=$(dd iflag=fullblock bs=4 count=1 | od -An -td4)
>> >>  length=$((length))      # trim leading spaces
>> >>  IFS= read -rN"$length" json
>> >>
>> >> That still winds up showing "Invalid byte sequence in conversion input"
>> >> when echo'ing the output to a file.
>> >
>> > Please show us the input.  Since it's binary, you'll need to represent
>> > it in some way that can fit into an e-mail body.  Perhaps a hex dump of
>> > the first 128 bytes or something.
>> >
>> > I'm rather curious what possible input could be an "invalid byte
>> sequence"
>> > when interpreted as 32 bits that make up an integer.  Is it having the
>> > high bit set (meaning negative when read as a signed integer)?
>> >
>> > unicorn:~$ printf '\x00\x00\x00\x80' | od -An -td4
>> > -2147483648
>> >
>> > Hmm, no, that looks all right to me.  Certainly didn't give that error.
>> >
>> > What operating system and architecture are you on, and what input are
>> you
>> > using to generate this message, and which program is actually writing
>> it?
>> >
>> >
>>
>