Notices

Try:
$ sudo gainroot
# bnf

You need to have rootsh package installed :-)
http://wiki.maemo.org/Root

Best wishes.
~~~~~~~~~~~~~~~~~
Per aspera ad astra...

same error. I dont knw wot d problem is. Could it be a hardware problem?

No, it looks like a misprint in the /usr/sbin/bnf-i2c file.
Like 45 for me:
NAC=$( $NAC * 3570 / $RS / 1000 ) # NAC Nominal available capacity, mAh.
No idea what's wrong with your file.

Best wishes.

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:
^ 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:
^ 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:
..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:
..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:
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:
NOTE, this error is produced by the stock busybox ash shell.

The busybox-power ash shell will instead print:
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:
..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:

Note, however, that if you do this change, the shell will swallow the syntax error of having a blank/unset value in any of the variables, instead of erroring out. To be honest though, I would be checking the return values of i2cget and returning out as soon as one returned an error value. Manpages online for i2cget seem to oh-so-helpfully not report what the return value will be in the event of a failure, but I imagine that, given Unix convention and the Linux kernel documentation on i2c that i2cget on the commandline returns 0 for success, something non-zero on failure, and I would hope i2cget takes care of printing its own errors to stderr....

So anyway, I would daisy-chain the VAR_NAME=$(i2cget [...]) commands with '&&', and stick them in a negated if check, so that you can abort out, like so:
And if i2cget fails to print useful errors to stderr, then you could wrap each i2cget call in a error-reporting wrapper e.g. something like:
..then call that instead of i2cget directly. But I really think (and hope) i2cget prints errors properly.

@speedonwilliam
Sorry, I've, somehow, missed update on this thread. Anyway, thanks for trying to solve/solving Wikiwide and Mentalist - indeed, do as Mentalist said, and we will be able to proceed after getting a meaningful output. If the "sudo i2cget" thing doesn't produce output, try issuing it without sudo, but from root shell.

@Mentalist Traceur
Thanks for your insights on the "code", all dully noted, I'll experiment with upgrading the script when I'll have some free time. BTW, that happens, when someone with actual knowledge inspects totally "noobishly" written code Well, at least I seem to *do* understand the mechanics behind your suggestions, and that is something, already...

/Estel

Happy to help. I spent an unhealthy amount of time figuring out Bourne/POSIX shell scripting details in the last half year. (I tend towards depth-first perfectionism when I do anything, so with increasing competence in shell scripting, came more and more digging into shell scripting nuance.)

"But will this one-off shell script break if a user has a newline in their input?" are the kinds of questions which keep me up at night.

Woops, I made an error, right here:
The above will also be a syntax error. Apparently, arithmetic expansion is one of those places where field splitting is not done when expanding variables to start with... So if you do have the double quotes there, the double quotes are treated as literals instead of as escapes around the variable contents.

Consequently, I am less confident about my assertion that $(($SOME_VAR + 1)) would be any less efficient than $((SOME_VAR + 1)). I guess I don't remember the parsing rules with regard to arithmetic expansion as well as I thought I did.

Thank you all for your help. I really appreciate it but d truth is i'm a noob :-D so I really dont understand what you guys are saying. Anyway thanks once again.

Tried the command below as root:
sudo i2cget -y 2 0x55 0x0c w
nothing happens. Also follöwed your instruction and tried it without sudo but from the root shell n i get thesame message:
Error: Read failed

OK, so for some reasons, your chip doesn't report nominal available capacity, at all... Now I just need to refresh my memory about what it means ;D