On 16/12/09 01:18, john blair wrote:
cat a | /build/toolchain/lin32/coreutils-8.2/bin/sort -V
kernel-2.6.18-164.2.1.el5.x86_64.rpm
kernel-2.6.18-164.6.1.el5.x86_64.rpm
kernel-2.6.18-164.el5.x86_64.rpm
The result should be
kernel-2.6.18-164.el5.x86_64.rpm
kernel-2.6.18-164.2.1.el5.x86_64.rpm
kernel-2.6.18-164.6.1.el5.x86_64.rpm
Is it a bug is sort -V?
The attached patch at least tries to explain this weirdness
(and also fixes up some out of date info about sort -V).
cheers,
Pádraig.
>From 3069d50b766a2db8b86406904b7327e5de5e315f Mon Sep 17 00:00:00 2001
From: =?utf-8?q?P=C3=A1draig=20Brady?= <[email protected]>
Date: Thu, 17 Dec 2009 10:48:54 +0000
Subject: [PATCH] doc: enhance and reference info about version comparison
* doc/coreutils.texi (sort invocation): Reference the additional
info about filevercmp rather than the unused strverscmp.
(Details about version sort): Add some examples that are not
handled well by fileversmp.
* src/ls.c: Change a comment referencing the now unused strverscmp.
---
doc/coreutils.texi | 33 ++++++++++++++++++++++++---------
src/ls.c | 2 +-
2 files changed, 25 insertions(+), 10 deletions(-)
diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index 3721bee..ab1c20a 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -3862,10 +3862,9 @@ To compare such strings numerically, use the
@opindex -V
@opindex --version-sort
@cindex version number sort
-...@vindex LC_NUMERIC
-Sort per @code{strverscmp(3)}. This is a normal string comparison, except
-that embedded decimal numbers are sorted by numeric value
-(see @option{--numeric-sort} above).
+Sort by version name and number. It behaves like a standard sort,
+except that each sequence of decimal digits is treated numerically
+as an index/version number. (@xref{Details about version sort}.)
@item -r
@itemx --reverse
@@ -6720,11 +6719,27 @@ abc-1.012b.tgz abc-1.007.tgz
abc-1.01a.tgz abc-1.012b.tgz
@end example
-This functionality is implemented using gnulib's @code{filevercmp} function.
-One result of that implementation decision is that @samp{ls -v}
-and @samp{sort -V} do not use the locale category, @env{LC_COLLATE},
-which means non-numeric prefixes are sorted as if @env{LC_COLLATE} were set
-to @samp{C}.
+This functionality is implemented using gnulib's @code{filevercmp} function,
+which has some caveats worth noting.
+
+...@itemize @bullet
+...@item @env{LC_COLLATE} is ignored, which means @samp{ls -v} and @samp{sort -V}
+will sort non-numeric prefixes as if the @env{LC_COLLATE} locale category
+was set to @samp{C}.
+...@item Some suffixes will not be matched by the regular
+expression mentioned above. Consequently these examples may
+not sort as you expect:
+
+...@example
+abc-1.2.3.4.7z
+abc-1.2.3.7z
+...@end example
+
+...@example
+abc-1.2.3.4.x86_64.rpm
+abc-1.2.3.x86_64.rpm
+...@end example
+...@end itemize
@node General output formatting
@subsection General output formatting
diff --git a/src/ls.c b/src/ls.c
index aeaa584..5c7f6aa 100644
--- a/src/ls.c
+++ b/src/ls.c
@@ -3272,7 +3272,7 @@ DEFINE_SORT_FUNCTIONS (extension, cmp_extension)
All the other sort options, in fact, need xstrcoll and strcmp variants,
because they all use a string comparison (either as the primary or secondary
sort key), and xstrcoll has the ability to do a longjmp if strcoll fails for
- locale reasons. Last, strverscmp is ALWAYS available in coreutils,
+ locale reasons. Last, filevercmp is ALWAYS available in coreutils,
thanks to the gnulib library. */
static inline int
cmp_version (struct fileinfo const *a, struct fileinfo const *b)
--
1.6.2.5
