OK,
I concede I can indeed do the one thing I need here by using decimal values with hex arithmetic, and it will give the right answer.
though it is truly horrible coding :-)
I can see situations where I'd want to do something like "add one to the last serial number I used" where decimal arithmetic would be needed.
For myself, I don't see any reason why an arithmetic command shouldn't be a special case ( in having the option to work in various bases ), it's doing a special job.
Sorry it took me a while to catch onto your clever trick, and thanks for your help.
David
In article 20091026120130.9538128B9B@gemini.denx.de, wd@denx.de (Wolfgang Denk) wrote:
*From:* Wolfgang Denk wd@denx.de *To:* from_denx_uboot@dexdyne.com *CC:* u-boot@lists.denx.de *Date:* Mon, 26 Oct 2009 13:01:30 +0100
Dear "David Collier",
In message <memo.20091026103604.2092e@postmaster+dexdyne.com.cix.co.uk> you wrote:
I did not only describe it, I tested it. I just "tricked" a bit. You asked to extract the last two digits, and I used "% 100" to
do
this. Note that this works correctly in any number base - may
it be > 10 or 16 or whatever :-)
Hey, that was clever, wasn't it? :-)
yeah it was - but of course I really wanted the next 2 digits as well.... I'm hoping to make more than 100 units really! pardon me for over-simplifying my question.
Then do the same with "% 10000" and "/ 100" ?
I wonder if it would be useful/helpful to allow the user to optionally over-ride the number base for reading and separately for writing by setexpr.
I don't see a need for it; certainly not here.
That would extend it's usefulness without requiring an extra command or breaking any existing code
No extra command is needed here.
setenv setexpr_in 10 setenv setexpr_out 16
If I wrote a patch would you look favourably on it?
I don't think so. If we did something like that, it should be generic and not restricted to one command. And it would break a LOT of existing scripts. And it is not needed at all, at least not for the use case you have in mind here. [If anything is worth implementing at all, then maybe the regexp handling present in standard expr command.]
Best regards,
Wolfgang Denk
-- DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de Testing can show the presense of bugs, but not their absence. -- Edsger Dijkstra
David Collier
www.dexdyne.com