Thread (6 messages) 6 messages, 2 authors, 2024-12-16

Re: [PATCH] strverscmp.3: this is NOT the ordering used by ls -v

From: Alejandro Colomar <alx@kernel.org>
Date: 2024-12-15 20:44:01

Hi nab,

On Sun, Dec 15, 2024 at 09:17:59PM +0100, Ahelenia Ziemiańska wrote:
Compare, given:
	#include <stdlib.h>
	#include <stdio.h>
	#include <string.h>
	int compar(const char **l, const char **r) {
		return strverscmp(*l, *r);
	}
	int main(int argc, char ** argv) {
		qsort(argv + 1, argc - 1, sizeof(*argv), compar);
		for(int i = 1; i <  argc; ++i)
			puts(argv[i]);
	}
yields:
	$ /bin/ls -v1 a*  # coreutils ls
	a-1.0a
	a-1.0.1a
	$ ../vers a*      # as above
	a-1.0.1a
	a-1.0a
	$ ls -v1 a*       # voreutils ls @ 5781698 with strverscmp()-equivalent sorting
	a-1.0.1a
	a-1.0a
Should we file a bug against glibc strverscmp(3)?  We probably should.
compare also the results for real data like
	netstat-nat-1.{0,1{,.1},2,3.1,4{,.{1,2,3,4,5,6,7,8,9,10}}}.tar.gz
Thus, coreutils ls -v does NOT use strverscmp(3),
it uses a similar algorithm that actually properly sorts versions,
not just single numbers.
First time I learn about ls(1) having a -v option.  :|
Was people too lazy to type `ls | sort -V`?
quoted hunk ↗ jump to hunk
Signed-off-by: Ahelenia Ziemiańska <redacted>
---
 man/man3/strverscmp.3 | 15 +++++----------
 1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/man/man3/strverscmp.3 b/man/man3/strverscmp.3
index 41bc1ddbd..7c3643860 100644
--- a/man/man3/strverscmp.3
+++ b/man/man3/strverscmp.3
@@ -25,16 +25,7 @@ .SH DESCRIPTION
 orders them
 .IR jan1 ", " jan10 ", ..., " jan2 ", ..., " jan9 .
 .\" classical solution: "rename jan jan0 jan?"
-In order to rectify this, GNU introduced the
-.I \-v
-option to
-.BR ls (1),
-which is implemented using
-.BR versionsort (3),
-which again uses
-.BR strverscmp ().
-.P
-Thus, the task of
+The task of
 .BR strverscmp ()
 is to compare two strings and find the "right" order, while
 .BR strcmp (3)
@@ -44,6 +35,10 @@ .SH DESCRIPTION
 .BR LC_COLLATE ,
 so is meant mostly for situations
 where the strings are expected to be in ASCII.
+This is not actually the ordering produced by
+.BR ls (1)
+.BR -v .
+.\" because it considers a-1.0.1a < a-1.0a; this is not what you want
I hate this reference to ls(1).  ls(1) should not even have a -v option.
Please refer to sort(1) instead.  I would wipe any references to file
names in this page, as I don't think they are relevant at all.

And the reference to sort(1), I'd put it in BUGS, saying that this API
is broken, and does not sort properly.  Sounds good?

Have a lovely night!
Alex
 .P
 What this function does is the following.
 If both strings are equal, return 0.
-- 
2.39.5


-- 
<https://www.alejandro-colomar.es/>

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help