Tiny Core Linux
Tiny Core Base => TCB Bugs => Topic started by: jazzbiker on February 12, 2020, 03:02:06 PM
-
Hi, Core people!
Bad news from BusyBox team - they decided to change dc applet command line syntax. They named this "much fuller version". This took place in BusyBox since 1.30 and in the latest TC11, which uses 1.31 I can't write
$dc 2 2 add p
and get
4
Happy user of the "fuller version" must write
$dc -e '2 2 + p'
By the way "add", "sub", "mul" and "div" keywords were thrown out, now we must use only +, -. * and / in string constants. How about * symbol in your commands ?
One of the direct consequencies is that "tce-size" utility ( called by tce ) now is showing rubbish, because it uses dc line calls for extension size arythmetics. Please, forgive my anger, but in order to have proper tce-size output data this script needs to be edited after so many years of excellent functioning.
Maybe there are other cases of dc applet use in TC system stuff. Probably all of them will fail too. (
-
That's a pretty big regression, as I'm sure other programs rely on 'dc'.
There seems to be a busybox option: FEATURE_BC_LONG_OPTIONS which can be enabled and might fix the problem.. see the config http://repo.tinycorelinux.net/11.x/x86_64/release/src/busybox/busybox-1.31.1_config.nosuid
I haven't tested.. it might be useful to look at the 'bc' source code as well: https://git.busybox.net/busybox/tree/miscutils/bc.c
-
:(
If any dc users would like to test the effect of FEATURE_BC_LONG_OPTIONS it would be much appreciated..
-
HI!
There are no references to bc functions in dc.c, and bc config options will not have any impact on dc behaviour. The main "improvement" is done in dc_main(), and it means, that getopt() is used, so dc command line is tested for the two switches "e" and "f" and no more.
Other "improvement" ( throwing out of keywords sub, add, etc ) is done by commenting with the help of //.
My first glance on the sources of 1.31 and 1.29 BB make me feel, that old dc behaviour can be restored by simply replacing of dc_main() with dc_main() from 1.29. This will eliminate e and f switches processing.
So we have two ways:
1. Patch TC system stuff in order to achieve new dc compatibility.
2. Patch dc in order to restore its native behaviour.
What's the choice?
P.S. As for me personally i will unconditionally patch the dc in order to use TC11
-
Hi jazzbiker
... So we have two ways:
1. Patch TC system stuff in order to achieve new dc compatibility.
2. Patch dc in order to restore its native behaviour. ...
3. Remove the dc requirement from the system stuff.
Attached are patches for 2 possible ways of removing dc:
1. The tce-size.sh.diff uses the shells built in math capabilities. It's not floating point math so all the numbers end in .00 and anything
smaller than 1 Meg shows up as 0.00. I personally never pay attention to the decimal places. The integer byte count is just to the
left of the "floating point" number if someone really cares about actual size. This patch runs just as fast as the dc version.
2. The tce-size.calc.diff uses the calc script which is just a wrapper for awk and it does do floating point math. It is a little slower
than the dc version. The time to populate the window when selecting the size tab for gtk3-dev.tcz in Apps is:
dc=3 Secs.
calc=4.5 Secs.
The only effected files I found were tce-size and filetool.sh.
-
The calc one looks good.
-
Hi,Rich!
The only effected files I found were tce-size and filetool.sh.
If really only this two files, the trouble is quite small. But if no (and for those like me, who used dc in their scripts) i attach promised patch for BB 1.31.1 dc.c with dc_main() replaced with the dc_main() from BB 1.29.3 and reenabled keywords for arythmetic operations.
Unfortunately, both ways demand rootfs.gz correction (
-
Hi curaga
The calc one looks good.
I have another one. It's a variation of a technique I used on an embedded processor that didn't have space for floating point code.
This is the function that does the work:
Fixed3Div()
{
# divide $1 by $2. Return result to 3 decimal places, no rounding.
printf "%d.%03d\n" $(($1 / $2)) $(((($1 % $2) * 1000) / $2))
}
The left side of the decimal point comes from the integer divide --> $(($1 / $2))
The fractional part is derived by dividing the remainder separately after multiplying by 1000 --> $(((($1 % $2) * 1000) / $2))
The printf command handles formatting the fractional part with leading zeros and a field width of 3 digits.
If a divisor of 2 Meg or larger is used there is the potential for overflow (sign reversal) of the fractional part. The divisor in
this application is always 1 MEG so it's not an issue.
This version is just as fast as the dc version.
-
Changes added to tc git - thanks
-
I love frugality. It's what computing should be.
-
Hi,
The only effected files I found were tce-size and filetool.sh.
Changes added to tc git - thanks
Well, only tce-size was corrected. filetool.sh wasn't and thus doesn't work.
One thing I don't understand is how it was not noticed: nobody uses filetool.sh? Isn't it a tool we should commonly use? What do people use instead?
-
One thing I don't understand is how it was not noticed: nobody uses filetool.sh? Isn't it a tool we should commonly use? What do people use instead?
Answering myself for that point: the calls to dc are only present in the path of the "Dry run" option, so one can use filetool.sh regularly and yet never encounter the bug as long as one doesn't use this option.
-
If somebody could propose a patch for filetool.sh, it will be added to tc git.
-
If somebody could propose a patch for filetool.sh
Here is one. I simply mimicked the patch that was made for tce-size.
Generated without a leading path with the following command:
diff -u filetool.sh.orig filetool.sh.fixedpoint > filetool.sh.fixedpoint.diff
(original version of the file being the one from github)
-
Applied, thanks.