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

[dan b]

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<mailto: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<http://hotmail.com>
sent via mobile.
+19059205138

On Jun 24, 2023, at 18:32, guest271314 
<guest271314@gmail.com<mailto: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<mailto: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?
>
>