Hello Paul, On Wed, Jun 26, 2019 at 12:57:14PM -0700, Paul Eggert wrote: > GNU sort uses the same algorithm as glibc strverscmp,
I think that both sort and ls use 'filevercmp' - a simplified version that does not support locales (and doesn't fail). The change (from 'strvercmp') was made in: commit e505736f8211a608b00dfe75fb186a5211e1a183 Author: Kamil Dudka <kdu...@redhat.com> Date: Fri Oct 3 11:03:40 2008 +0200 ls and sort: use filevercmp instead of strverscmp https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=e505736f8211a608b00dfe75fb186a5211e1a183 > Has the Debian version-comparison algorithm changed since 1997? If so, could > you give details about the changes to the Debian algorithm? I don't think the algorithm changed in Debian, and also in gnulib there are only a handful of relevant commits, all 10 years old: 9121662f1 2008-10-03 filevercmp: new module 0443c2f39 2009-03-05 filevercmp: Move hidden files up in ordering. 1721cf06d 2009-03-24 filevercmp: handle simple~ and numbered.~3~ backup suffixes 4fd008794 2009-04-09 filevercmp: fix regression cc96df30d 2009-04-09 filevercmp: correct today's change I think (also based on Ian's confirmation) that this discrepancy was from the beginning. I now notice that there's an additional difference: coreutils/gnulib has special handling for extension, hidden files and backup files. As Ian wrote, a documentation improvement is probably the best fix. I'll try to come up with a suggested change. -assaf P.S. For completion, here are few other threads with details/explanations about 'version-sort': https://bugs.gnu.org/18168 https://bugs.gnu.org/22275 https://bugs.gnu.org/22455 https://bugs.gnu.org/33786
