bug#49239: Unexpected results with sort -V

[Michael Debertol]

Am 28.06.21 um 18:41 schrieb Kamil Dudka:
> On Sunday, June 27, 2021 12:04:53 AM CEST Michael wrote:
> > Hi,
> > I found some unexpected results with sort -V. I hope this is the correct
> > place to send a bug report to [1].
> > They are caused by a bug in filevercmp inside gnulib, specifically in the
> > function match_suffix.
> > I assume it should, as documented, match a file ending as defined by this
> > regex: /(\.[A-Za-z~][A-Za-z0-9~]*)*$/
> > However, I found two cases where this does not happen:
> > 1) Two consecutive dots. It is not checked if the character after a dot is
> > a dot. This results in nothing being matched in a case like "a..a", even
> > though it should match ".a" according to the regex.
> > Testcase: printf "a..a\na.+" | sort -V # a..a should be before a.+ I think
> > 2) A trailing dot. If there is no additional character after a dot, it is
> > still matched (e.g. for "a." the . is matched).
> > Testcase: printf "a.\na+" | sort -V # I think a+ should be before a.
> As far as I understand, regex (\.[A-Za-z~][A-Za-z0-9~]*)*$ specifies that each
> dot has to be followed by [A-Za-z~] to be matched.  Am I missing anything?
>
> I am not saying that the current behavior is perfect (a solution that works as
> expected in all scenarios is difficult to find in this case) but, at least, it
> seems to me that it works as it is described.

I was trying to say that the regex is not followed in two cases:

- when there are two dots followed by [A-Za-z~], the second dot should 
be matched, but it is not.

An example is "foo..a": In this case ".a" should be matched, but it is 
not (nothing is matched)

- when there's a trailing dot, the trailing dot is matched even though 
it is not followed by anything

e.g. "foo." matches the "." as the file ending, but it should not match 
a file ending in this case.

I hope it's clearer now,

Michael