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
