GNU bug report logs - #49239
Unexpected results with sort -V

Previous Next

Full log

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Kamil Dudka <kdudka <at> redhat.com>
To: Michael <michael.debertol <at> gmail.com>
Cc: 49239 <at> debbugs.gnu.org, bug-coreutils <at> gnu.org
Subject: Re: 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.