On 6/17/20 7:22 AM, Jacek Wielemborek wrote:
Hi!
First of all, thanks for maintaining GNU sort! I use it very often and love
its performance.
Today I spent some time debugging and realized that my bug was caused by a
wrong GNU invocation ("sort -k1,1 -t," instead of "sort -t, -k1,1"). Could
sort warn when -t is effectively a no-op because it was specified after
last -k?
Except that statement does not appear to be true. sort does not care
whether -t comes before or after -k; there is no interlocking between
the two options (looking at the source code, nothing under case 't' [1]
depends on the current set of keys, and nothing under case 'k' [2]
depends on the current 'tab').
[1] https://git.sv.gnu.org/cgit/coreutils.git/tree/src/sort.c#n4520
[2] https://git.sv.gnu.org/cgit/coreutils.git/tree/src/sort.c#n4441
To convince me otherwise, could you include actual input where the
relative ordering of the two options produces different output?
I know that `find` warns the user if arguments are in a wrong
order, perhaps it would make sense to add it here as well?
We have 'sort --debug' for this sort of things. If the ordering truly
mattered, then yes, --debug should warn about that. But I can't see the
ordering matter. Here's what I tried, where the first two tries show
that the position of -t, doesn't affect the output, and the third shows
that omitting -t, does matter:
$ printf '1,2 3\n2,1 4\n' | LC_ALL=C sort -k2,2 -t, --debug
sort: text ordering performed using simple byte comparison
2,1 4
___
_____
1,2 3
___
_____
$ printf '1,2 3\n2,1 4\n' | LC_ALL=C sort -t, -k2,2 --debug
sort: text ordering performed using simple byte comparison
2,1 4
___
_____
1,2 3
___
_____
$ printf '1,2 3\n2,1 4\n' | LC_ALL=C sort -k2,2 --debug
sort: text ordering performed using simple byte comparison
sort: leading blanks are significant in key 1; consider also specifying 'b'
1,2 3
__
_____
2,1 4
__
_____
I'll leave this bug open a bit longer to allow you to reply with the
counterexample that behaved differently based solely on ordering, but
I'm inclined to close it if we can't come up with such a case.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
