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
