Re: sort -V behaviour

[Sven C. Dack]

Hello Kaz,

thank you for your explanation.

Looks like I'll have to work around it.

It would be nice if one could somehow specify a flag to disable this 
behaviour and to make 'sort' less clever about file extensions, because 
with 'sort' is the context not always file names. It's not the 'ls' 
command, but it's a universal sorting command for all kinds of data. At 
least this is how I have always treated it.


On 31/07/17 19:41, Kaz Kylheku (Coreutils) wrote:
...
> > This behaviour is unintuitive and seems wrong to me.
>
> I agree that the specification is not ideal, but it's not easy to
> see how it can be improved given the threat of numeric junk like 7z
> which cannot be treated as part of the version.
>
> Consider that 1.7z looks like a bigger version than 1.2.7z,
> if the 7 is wrongly treated as part of the version!!!
>
> The designers who specified the filevercmp function were clearly
> sober to these cases.

I understand your reasoning, but I cannot agree with it. As you yourself 
have realized does 1.7z indeed look like it's a higher version than 
1.2.7z (that's because to many people it just is).

Only because of you recognizing 7z as a file extension (used by 7-zip) 
should the 'sort' command not automatically recognize file extensions, 
too. If you look at 
https://www.file-extensions.org/extensions/begin-with-number then you'll 
see that there are far too many extensions including many, which are 
numbers. Strangely enough could I not find an extension ending in a "/" 
for that matter...

I can certainly see how within the context of file names the behaviour 
makes a variety of use cases easier, but the input to the 'sort' command 
generally makes no assumptions about the context. It doesn't assume all 
strings to be surnames, or that all numbers are currencies, or taxable, 
or that these can be rounded the nearest penny or cent for example.

So I'm going blame it on the use of the filevercmp() function. Obviously 
was it designed specifically for file names and not as a universal 
version number comparison function.

Cheers,
Sven