Version: (using KDE KDE 3.5.2) Installed from: SuSE RPMs OS: Linux Bash's $(()) can only do integer arithmetic. I suggest to check for bc and use it instead of $(()), if it is installed.
This here should do: QString Minicli::calculate(const QString &exp) { QString result; QString cmd = QString("if [ -x \"$(which bc)\" ]; then echo \"%1\" | bc -l; else echo $((%1)); fi").arg(exp); FILE *fs = popen(QFile::encodeName(cmd).data(), "r"); if (fs) { QTextStream ts(fs, IO_ReadOnly); result = ts.read().stripWhiteSpace(); pclose(fs); } return result; }
"Real numbers in math expression patch", not decimal of course - sorry bout that.
SVN commit 586065 by dfaure: Make 1.2+3.4 work in minicli, using bc, based on patch/idea by Konrad Miller. It has annoyed me a few times that only integers worked due to using $(()) indeed. BUG: 134282 M +6 -2 minicli.cpp --- branches/KDE/3.5/kdebase/kdesktop/minicli.cpp #586064:586065 @@ -859,8 +859,12 @@ QString Minicli::calculate(const QString &exp) { - QString result; - QString cmd = QString("echo $((%1))").arg(exp); + QString result, cmd; + const QString bc = KStandardDirs::findExe("bc"); + if ( !bc.isEmpty() ) + cmd = QString("echo %1 | %2").arg(KProcess::quote(exp), KProcess::quote(bc)); + else + cmd = QString("echo $((%1))").arg(exp); FILE *fs = popen(QFile::encodeName(cmd).data(), "r"); if (fs) {
I made the check more kde-like, which might make this work with C shells too, added quoting to avoid problems with special characters (just in case), and didn't use bc -l just in case there are versions of bc out there that don't support -l; doesn't change anything for simple real-numbers-arithmetic anyway, and minicli doesn't trigger bc if you add a function call anyway... Thanks for the idea, David.
Thank you for the fast response :). Konrad
If you don't use the -l switch in bc, "real" division doesn't work, btw.. dfi@shadow ~ $ echo "1.5/3" | bc 0 Konrad
reopen
You don't need to invoke -l. Setting the bc scale variable works also. But what should it be set to? dfi@shadow ~ $ echo "scale=2; 1.5/3" | bc .50 Sorry for spamming so much in here - but this thing bothers me... Konrad
On Tuesday 19 September 2006 10:42, Stephan Kulow wrote: > Am Montag, 18. September 2006 18:01 schrieb David Faure: > > SVN commit 586065 by dfaure: > > > > Make 1.2+3.4 work in minicli, using bc, based on patch/idea by Konrad > > Miller. It has annoyed me a few times that only integers worked due to > > using $(()) indeed. BUG: 134282 > > > I just hope that people don't confuse minicli with a calculator or they will > wonder why the finance office refuses their papers :) > > coolo@portia#~>echo "12*0.2" | bc > 2.4 > coolo@portia#~>echo "12/5" | bc > 2 Interesting, this is exactly what Konrad miller just mentionned in #134282: this was the reason he had used "bc -l", which I removed because I didn't know it did that, and I didn't know if all versions of bc had it. So it sounds like re-adding -l would be a good idea, to fix the above problem, except that it leads to "2.40000000000000000000" which is a bit annoying. echo "scale=2; 12/5" | bc says 2.40, but I wonder why bc doesn't have a mode where it simply removes the useless trailing zeros... Well, we could do it in code of course...
On Wednesday, 20. September 2006 16:59, David Faure wrote: > echo "scale=2; 12/5" | bc > says 2.40, but I wonder why bc doesn't have a mode where it simply removes > the useless trailing zeros... Well, we could do it in code of course... The -l option also includes the advanced bc functions (mathlib), and does so on all platforms. The modification of scale= (precision) is just a side effect of -l. Kris
SVN commit 586801 by dfaure: OK with a scale set, divisions work, and only them display lots of zeros, a+b and a-b don't so this is ok imho. BUG: 134282 M +1 -1 minicli.cpp --- branches/KDE/3.5/kdebase/kdesktop/minicli.cpp #586800:586801 @@ -862,7 +862,7 @@ QString result, cmd; const QString bc = KStandardDirs::findExe("bc"); if ( !bc.isEmpty() ) - cmd = QString("echo %1 | %2").arg(KProcess::quote(exp), KProcess::quote(bc)); + cmd = QString("echo %1 | %2").arg(KProcess::quote(QString("scale=8; ")+exp), KProcess::quote(bc)); else cmd = QString("echo $((%1))").arg(exp); FILE *fs = popen(QFile::encodeName(cmd).data(), "r");
I don't know if you want to hear this, but bash can do this... i=$(echo "12/5" | bc -l) && i="${i//%0*/}" && echo "${i//%\./.0}" The first expression removes trailing zeros, the second adds a 0 if the last caracter is a '.'. HTH, Konrad
> The first expression removes trailing zeros ... including those that are not after a decimal point ;) > i=$(echo "120" | bc -l) && i="${i//%0*/}" && echo "${i//%\./.0}" 12 Anyway, I could remove the trailing zeros in C++, I'm just surprised that bc doesn't do it, and I also don't think it will be a big issue; I personally only ever used minicli for + and -, divisions don't happen that often in real life, or a real calculator ends up being useful then.
Am Mittwoch, 20. September 2006 16:58 schrieb David Faure: > On Tuesday 19 September 2006 10:42, Stephan Kulow wrote: > > Am Montag, 18. September 2006 18:01 schrieb David Faure: > > > SVN commit 586065 by dfaure: > > > > > > Make 1.2+3.4 work in minicli, using bc, based on patch/idea by Konrad > > > Miller. It has annoyed me a few times that only integers worked due to > > > using $(()) indeed. BUG: 134282 > > > > I just hope that people don't confuse minicli with a calculator or they > > will wonder why the finance office refuses their papers :) > > > > coolo@portia#~>echo "12*0.2" | bc > > 2.4 > > coolo@portia#~>echo "12/5" | bc > > 2 > > Interesting, this is exactly what Konrad miller just mentionned in #134282: > this was the reason he had used "bc -l", which I removed because I didn't > know it did that, and I didn't know if all versions of bc had it. > So it sounds like re-adding -l would be a good idea, to fix the above > problem, except that it leads to "2.40000000000000000000" which is a bit > annoying. > > echo "scale=2; 12/5" | bc > says 2.40, but I wonder why bc doesn't have a mode where it simply removes > the useless trailing zeros... Well, we could do it in code of course... I guess scale=2 will be fine Greetings, Stephan
Bug closed. Kdesktop is no more mantained.
Why do you change a lot of bug's status from RESOLVED to CLOSED? (What exactly is the difference? They still have a "resolution" so it makes sense that they are RESOLVED.) And what do you mean with "Kdesktop is no more mantained."? I thought that Kdesktop is an important part of a current KDE release?
The difference is that "CLOSED" means that the problem is completely solved and no further actions will be taken on that issue. KDesktop is an important part of KDE, right, but the mantainer/developer doesn't works on it anymore. He agreed with me to close them. If the problem is important to be solved: 1) it shouldn't be had marked as FIXED 2) it should be checked if KDE 4 has the same problem 3) if both suffer of the same problem, it could be opened a new bug report against KDE 4.