Based on the "double" bug #503598, this is a simplification of there, for the qsize from app-portage/portage-utils. --------------- Bug/enhancement (copy/pasted): The qsize output is rare for the European and South America countries. For example, if I need the size of lsof, the output is: $ qsize lsof sys-process/lsof-4.85-r2: 30 files, 9 non-files, 434.593 KB In half world, it seems to be 424MB. It doesn't use the LC_NUMERIC variable for print the commas or dots. Plus, I vote for the use of 2 decimals instead of 3. The correct output and that's recommended is, for the half world: sys-process/lsof-4.85-r2: 30 files, 9 non-files, 434,59 KB Other bigger packages not seems this problem, like qtcore. Here no cause read problems, because more than 3 entire numbers: dev-qt/qtcore-4.8.5-r1: 1554 files, 210 non-files, 30342.245 KB And if qsize applying BLOCK_SIZE and LC_NUMERIC variables correctly, this output can be transform to this: dev-qt/qtcore-4.8.5-r1: 1554 files, 210 non-files, 30.342,245 KB or LC_NUMERIC="en_GB", for example: dev-qt/qtcore-4.8.5-r1: 1554 files, 210 non-files, 30,342.245 KB or in bytes with LC_NUMERIC="es_ES.UTF-8": dev-qt/qtcore-4.8.5-r1: 1554 files, 210 non-files, 31.070.459 bytes I think that if app-portage/portage-utils read these variables, these numbers can be read to the same format that gnu file utilities, for standarize, and the -k and -b options can be deleted (or not).
BLOCK_SIZE isn't really standard ... BLOCKSIZE is used by one or two tools, but even that isn't common. besides, qsize doesn't give you information in blocks, so checking that doesn't make sense at all.
should be fixed by: http://git.overlays.gentoo.org/gitweb/?p=proj/portage-utils.git;a=commitdiff;h=a235b67877128a5ab23388cabb0a31bf3502094e and building portage-utils with USE=nls
Thanks SpanKY (yes, +3 years later)!
