View Single Post
Posts: 2,225 | Thanked: 3,822 times | Joined on Jun 2010 @ Florida
#84
Ugh, initially I wrote: "Not bothering to look inside the script itself, but some comments which may help the next person to look zero in on the problem"... but then nooo... I just had to go digging.

Anyway, I looked at this and it looked wrong, so I figured it was a someone-wrote-out-what-they-thought-they-saw-instead-of-copy-pasting style of error. And sure enough, this is wrong, that is not what line 45 looks like:
Code:
NAC=$( $NAC * 3570 / $RS / 1000 )
^ Unless $NAC at that moment is defined as the name of a valid command, that's going to be a command-not-found error anyway...

Looking at the line as quoted, I would imagine you meant arithmetic expansion rather than command substition? If so, it would look like this:
Code:
NAC=$(($NAC * 3570 / $RS / 1000))
^ I went ahead and looked into the source code, and indeed, that's what it looks like. (Note the double '((' and '))' symbols.)

As a sidenote, this assumes $NAC and $RS will never have whitespace inside them (or be blank). I habitually double-quote any usage of $VAR_NAME unless I expressly know it's guaranteed to be unnecessary. So it would look like so:
Code:
NAC=$(("$NAC" * 3570 / "$RS" / 1000))
..though it's not a big deal because either way you'd get a syntax error if there's whitespace in either of those variables.

However, while we're at it, the dollar signs (and thus doublequotes) are actually redundant. Since this is an arithmetic expansion we're working with, we can just write:
Code:
NAC=$((NAC * 3570 / RS / 1000))
..because Bourne/POSIX shell syntax expects all non-number tokens inside the arithmetic expansion to be variable names anyway. (I suspect that this would be a miniscule bit more efficient, because this way the shell does not have to stop to expand the $VAR_NAMEs into text first, before proceeding with parsing the result of that expansion as part of the arithmetic expansion, and instead can do just the arithmetic expansion - one expansion instead of two, where the two expansions probably forces it to shuffle/rewrite some buffer contents.)

Anyway, back to the syntax error:
usr/sbin/bnf-i2c: line 45: syntax error: * 3570 / 20 / 1000
This is happening because "$NAC" is an empty string (or just completely unset, which for this purpose is the same thing).

Here is an example test command replicating that kind of syntax error:
Code:
$ A= B=1; echo $(($A * $B))
sh: syntax error:  * 1
NOTE, this error is produced by the stock busybox ash shell.

The busybox-power ash shell will instead print:
Code:
-sh: arithmetic syntax error
Which is both surprising, and amusing (because I'd expect busybox-power to have the more informative error message, and I find the lack of error-causing-string to be less informative...).

Anyway, point is, we see that $NAC is defined on line 16 (of the same file, obviously) with the command:
Code:
i2cget -y 2 0x55 0x0c w
..since bnf-i2c is ran as root (because bnf itself is ran as root), you'd need to run the above command as root, and see what it returns.

So, speedonwilliam, try running the following and let us know what the result is:

Code:
sudo i2cget -y 2 0x55 0x0c w
__________________
If you want to donate in support of anything that I do, you can do so with either of these options:
PayPal | Bitcoin: 1J4XG2z97iFEKNZXThHdFHq6AeyWEHs8BJ | [Will add other donation options eventually]

Last edited by Mentalist Traceur; 2014-12-01 at 06:28. Reason: s/whitespace inside them/whitespace inside them (or be blank)/
 

The Following 3 Users Say Thank You to Mentalist Traceur For This Useful Post: