Re: sort -V behaviour

[Kamil Dudka]

On Monday, July 31, 2017 17:23:16 Sven C. Dack wrote:
> Hello,
> 
> I have a question about the -V option to sort, but first some examples:
> 
> $ echo -e "1\n1.2\n1.2.3\n1.2.3.4"|sort -V
> 1
> 1.2
> 1.2.3
> 1.2.3.4
> 
> $ echo -e "f1\nf1.2\nf1.2.3\nf1.2.3.4"|sort -V
> f1
> f1.2
> f1.2.3
> f1.2.3.4
> 
> $ echo -e "/1\n/1.2\n/1.2.3\n/1.2.3.4"|sort -V
> /1
> /1.2
> /1.2.3
> /1.2.3.4
> 
> $ echo -e "1f\n1.2f\n1.2.3f\n1.2.3.4f"|sort -V
> 1f
> 1.2f
> 1.2.3f
> 1.2.3.4f
> 
> $ echo -e "1/\n1.2/\n1.2.3/\n1.2.3.4/"|sort -V
> 1.2.3.4/
> 1.2.3/
> 1.2/
> 1/
> 
> My question is, why does the -V option reverse the order in the last case?

The version compare predicate used in 'sort -V' was originally designed for 
sorting (base) file names in the output of 'ls -v' and the '/' character is 
not allowed in (base) file names.

The gnulib function implementing the predicate is called filevercmp(), which 
makes it obvious what it does.  But I guess that we should say it explicitly 
in the documentation of 'sort -V' to avoid false expectations like this...

Kamil

> This behaviour is unintuitive and seems wrong to me. When -V sorts
> version numbers of files/lines/etc. and assumes a version number of i.e.
> "1.2.3" to be higher than "1.2" then it shouldn't matter if the version
> number is part of a file or a directory name.
> 
> Can somebody please explain this behaviour?
> 
> Sven