Re: Human readable sort
Pádraig Brady wrote: > Latest version attached. ... > * NEWS: Document the new option > * doc/coreutils.texi (sort invocation): ditto > * src/sort.c (main): handle the new --human-numeric-sort option (-h). > (human_numcompare): A new function to compare SI and IEC suffixes > before falling back to the standard --numeric comparison. > (find_unit_order): A new helper function to find the order > of magnitude of a number string as determined by its suffix. > (check_mixed_SI_IEC): A new helper function to exit with error > if both SI and IEC suffixes are presented. Looks fine. Thank you, Pádraig and Michael. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Human readable sort
Jim Meyering wrote:
Maybe s/unambiguously/consistently/
or /uniformly/
and mention that it's the inconsistent precision that causes trouble.
J. Random Bystander (i.e. me) prefers "consistently". ("Consistent", as
in, using the same rules. "Uniformly" to me suggests maybe some other
condition(s) as well.)
Thanks for adjusting the example. Also, thanks for finally pushing this
forward, it's been wanted for quite some time :-).
--
Matthew
Please do not quote my e-mail address unobfuscated in message bodies.
--
Sorry, not a winner. Please try again.
___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: "tr" fails to work with unicode strings
Roman Mamedov wrote: > Hello. > > Looks like the "tr" program does not work with UTF-8 strings properly. > I am attaching a screenshot. > This is with tr from GNU coreutils version 6.10. This is a known issue. We're working on it. thanks, Pádraig. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils 7.4 build: previous declaration of '__u32' was here
On Tuesday 26 May 2009 17:05:29 Kamil Dudka wrote: > On Tuesday 26 of May 2009 22:55:37 Poor Yorick wrote: > > Building coreutils to install in an alternate location which has its own > > libcap and glibc (self-compiled): > > > > CC ls.o > > In file included from ls.c:43: > > > > /path/to/include/sys/capability.h:34: error: redefinition of typedef > > '__u32' > > > > /path/to/glibc/include/asm-generic/int-ll64.h:24: note: previous > > declaration of '__u32' was here > > > > Any suggestions on the root cause or workaround for this? > > It might be caused by this bug: > https://bugzilla.redhat.com/show_bug.cgi?id=483548 > > As workaround you can try to move sys/capability.h include down in the > order. I am not sure now if this is the right point in your case, but worth > to try anyway. just look at sys/capability.h itself. the bug is right -- it's a mess. remove all the crap from that header and everything "magically" works. http://sources.gentoo.org/sys-libs/libcap/files/libcap-2.16-drop-linux- workarounds.patch -mike ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: coreutils 7.4 build: previous declaration of '__u32' was here
On Tuesday 26 of May 2009 22:55:37 Poor Yorick wrote: > Building coreutils to install in an alternate location which has its own > libcap and glibc (self-compiled): > > CC ls.o > In file included from ls.c:43: > > /path/to/include/sys/capability.h:34: error: redefinition of typedef > '__u32' > > /path/to/glibc/include/asm-generic/int-ll64.h:24: note: previous > declaration of '__u32' was here > > Any suggestions on the root cause or workaround for this? It might be caused by this bug: https://bugzilla.redhat.com/show_bug.cgi?id=483548 As workaround you can try to move sys/capability.h include down in the order. I am not sure now if this is the right point in your case, but worth to try anyway. Kamil ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
coreutils 7.4 build: previous declaration of '__u32' was here
Building coreutils to install in an alternate location which has its own libcap and glibc (self-compiled): CC ls.o In file included from ls.c:43: /path/to/include/sys/capability.h:34: error: redefinition of typedef '__u32' /path/to/glibc/include/asm-generic/int-ll64.h:24: note: previous declaration of '__u32' was here Any suggestions on the root cause or workaround for this? -- Nathan ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
"tr" fails to work with unicode strings
Hello. Looks like the "tr" program does not work with UTF-8 strings properly. I am attaching a screenshot. This is with tr from GNU coreutils version 6.10. -- With respect, Roman <> signature.asc Description: PGP signature ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
Re: Human readable sort
Jim Meyering wrote:
>
> Please make one small change to that log message:
>
> s/ -human/ --human/
>
> And in the documentation,
>
> +Sort numerically, as per the @option{--numeric-sort} option,
> +and in addition handle IEC or SI suffixes like MiB, MB etc.
> +Note a mixture of these suffixes is not supported and will
> +be flagged as an error. Also the numbers must be abbreviated unambiguously.
> +I.E. 5000K and 6M will be sorted incorrectly for example.
>
> Eventually, it'd be nice to explain in detail why those
> would cause trouble.
>
> Maybe s/unambiguously/consistently/
> or /uniformly/
> and mention that it's the inconsistent precision that causes trouble.
>
> Hmm actually those two *are* sorted properly for me:
>
> $ printf '%s\n' 5000K 6M| src/sort --human
> 5000K
> 6M
>
> However, these two are not:
>
> $ printf '%s\n' 7000K 6M| src/sort --human
> 7000K
> 6M
>
Latest version attached.
cheers,
Pádraig.
>From 159faba1376ffd5a46fe4bbc780d85dd3e502cea Mon Sep 17 00:00:00 2001
From: Michael Speer
Date: Mon, 27 Apr 2009 14:51:29 +0100
Subject: [PATCH] sort: new --human-numeric-sort option to sort KiB MB etc.
* NEWS: Document the new option
* doc/coreutils.texi (sort invocation): ditto
* src/sort.c (main): handle the new --human-numeric-sort option (-h).
(human_numcompare): A new function to compare SI and IEC suffixes
before falling back to the standard --numeric comparison.
(find_unit_order): A new helper function to find the order
of magnitude of a number string as determined by its suffix.
(check_mixed_SI_IEC): A new helper function to exit with error
if both SI and IEC suffixes are presented.
* tests/misc/sort: Add 8 tests to test the new functionality.
* THANKS: Update
---
NEWS |3 +
THANKS |1 +
doc/coreutils.texi | 15 +++
src/sort.c | 115
tests/misc/sort| 18
5 files changed, 144 insertions(+), 8 deletions(-)
diff --git a/NEWS b/NEWS
index 3af06e4..29b09a0 100644
--- a/NEWS
+++ b/NEWS
@@ -11,6 +11,9 @@ GNU coreutils NEWS-*- outline -*-
chroot now accepts the options --userspec and --groups.
+ sort accepts a new option, --human-numeric-sort (-h): sort numbers
+ while honoring human readable suffixes like KiB and MB etc.
+
* Noteworthy changes in release 7.4 (2009-05-07) [stable]
diff --git a/THANKS b/THANKS
index cf801c5..4392f04 100644
--- a/THANKS
+++ b/THANKS
@@ -396,6 +396,7 @@ Michael J. Croghan mcrog...@usatoday.com
Michael McFarland sid...@yahoo.com
Michael McLagan mmcla...@invlogic.com
Michael Piefel pie...@informatik.hu-berlin.de
+Michael Speer knome...@gmail.com
Michael Steffensmichael.steff...@s.netic.de
Michael Stone mst...@debian.org
Michael Stutz st...@dsl.org
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 97ea830..834bd46 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -3785,6 +3785,21 @@ Use this option only if there is no alternative; it is much slower than
@option{--numeric-sort} (@option{-n}) and it can lose information when
converting to floating point.
+...@item -h
+...@itemx --human-numeric-sort
+...@itemx --sort=human-numeric
+...@opindex -h
+...@opindex --human-numeric-sort
+...@opindex --sort
+...@cindex human numeric sort
+...@vindex LC_NUMERIC
+Sort numerically, as per the @option{--numeric-sort} option below, and in
+addition handle IEC or SI suffixes like MiB, MB etc (@ref{Block size}).
+Note a mixture of IEC and SI suffixes is not supported and will
+be flagged as an error. Also the numbers must be abbreviated uniformly.
+I.E. values with different precisions like 6000K and 5M will be sorted
+incorrectly.
+
@item -i
@itemx --ignore-nonprinting
@opindex -i
diff --git a/src/sort.c b/src/sort.c
index 6dea2ff..8438c05 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -176,6 +176,8 @@ struct keyfield
bool random; /* Sort by random hash of key. */
bool general_numeric; /* Flag for general, numeric comparison.
Handle numbers in exponential notation. */
+ bool human_numeric; /* Flag for sorting by human readable
+ units with either SI xor IEC prefixes. */
bool month; /* Flag for comparison by month name. */
bool reverse; /* Reverse the sense of comparison. */
bool version; /* sort by version number */
@@ -337,6 +339,9 @@ Ordering options:\n\
-M, --month-sortcompare (unknown) < `JAN' < ... < `DEC'\n\
"), stdout);
fputs (_("\
+ -h, --human-numeric-sortcompare human readable numbers (e.g., 2K 1G)\n\
+"), stdout);
+ fputs (_("\
-n, --numeric-sort compare according to string numerical value\n\
-R, --random-sort sort by random hash of keys\n\
--r
Re: [PATCH] chroot specify user/group feature
I wrote: > Giuseppe Scrivano wrote: ... > I rewrote parts of the .texinfo documentation and removed a paragraph, > since now that the new options are documented, it seemed redundant. > I'll merge these 4 change sets into yours and push late today or > tomorrow, to give people time for any additional feedback. > >>From fe77420a0ed029100f413173be79c678cd346064 Mon Sep 17 00:00:00 2001 > From: Jim Meyering > Date: Mon, 25 May 2009 14:55:39 +0200 > Subject: [PATCH 1/4] sort things, cpp-indent > Subject: [PATCH 2/4] don't include xalloc.h: system.h already does that > Subject: [PATCH 3/4] Avoid new warning, fix diagnostic, remove curly braces > Subject: [PATCH 4/4] tweak documentation Merged and pushed. Thanks again. ___ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
