bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#49239: Unexpected results with sort -V


From: Kamil Dudka
Subject: bug#49239: Unexpected results with sort -V
Date: Mon, 28 Jun 2021 18:41:17 +0200

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.

Kamil







reply via email to

[Prev in Thread] Current Thread [Next in Thread]