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

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 1214 bytes --]

Hi,

On Sun, Dec 15, 2024 at 10:02:42PM +0100, наб wrote:
> > Should we file a bug against glibc strverscmp(3)?  We probably should.
> > 
> > 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?
> No, this API works as-documented, and the implementation is useful.

What does useful mean?

> It's just not what ls -v does.

While version sort isn't something standard, I think GNU should be
self-consistent.

> @@ -44,6 +33,10 @@ .SH DESCRIPTION
>  .BR LC_COLLATE ,
>  so is meant mostly for situations
>  where the strings are expected to be in ASCII.
> +This is different from the ordering produced by
> +.BR sort (1)
> +.BR -V .
> +.\" because it considers a-1.0.1a < a-1.0a; this is not what you want

Re: "it": sort(1) -V or strverscmp(3)?
    (it's the latter, I think, but don't use "it".)

Re: "this is not what you want": Who is "you"?  What is "this"?  And why
    does "you" not want "this"?
    Please clarify.

Cheers,
Alex

>  .P
>  What this function does is the following.
>  If both strings are equal, return 0.
> -- 
> 2.39.5
> 



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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]