GNU bug report logs -
#49239
Unexpected results with sort -V
Previous Next
Full log
View this message in rfc822 format
On 13/02/2022 05:31, Paul Eggert wrote:
> On 6/28/21 10:54, Kamil Dudka wrote:
>> You are right. The matching algorithm was not implemented correctly and
>> the patch you attached fixes it.
>
> I looked into Bug#49239 and found some more places where the
> documentation disagreed with the code. I installed the attached patches
> into Gnulib and Coreutils, respectively, which should bring the two into
> agreement and should fix the bugs that Michael reported albeit in a
> different way than his proposed patch. Briefly:
>
> * The code didn't allow file name suffixes to be the entire file name,
> but the documentation did. Here I went with the documentation. I could
> be talked into the other way; it shouldn't matter much either way.
>
> * The code did the preliminary test (without suffixes) using strcmp, the
> documentation said it should use version comparison. Here I went with
> the documentation.
>
> * As Michael mentioned, sort -V mishandled NUL. I fixed this by adding a
> Gnulib function filenvercmp that treats NUL as just another character.
>
> * As Michael also mentioned, filevercmp fell back on strcmp if version
> sort found no difference, which meant sort's --stable flag was
> ineffective. I fixed this by not having filevercmp fall back on strcmp.
>
> * I fixed the two-consecutive dot and trailing-dot bugs Michael
> mentioned, by rewriting the suffix finder to not have that confusing
> READ_ALPHA state variable, and to instead implement the regular
> expression's nested * operators in the usual way with nested loops.
>
> Thanks, Michael, for reporting the problem. I'm boldly closing the
> Coreutils bug report as fixed.
A very thorough analysis.
All looks good.
thank you!
Pádraig
This bug report was last modified 3 years and 94 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.