GNU bug report logs - #41920
sort: bug report/feature request: warn is -t is effectively a no-op?

Previous Next

To reply to this bug, email your comments to 41920 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jacek Wielemborek <mail <at> d33.pl>
To: bug-coreutils <at> gnu.org
Subject: sort: bug report/feature request: warn is -t is effectively a no-op?
Date: Wed, 17 Jun 2020 14:22:47 +0200

[Message part 1 (text/plain, inline)]

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? 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?

(I read FAQ/list of gotchas, but believe that my case is a bit different
compared to the ones listed there)

Cheers,
d33tah

[Message part 2 (text/html, inline)]

Message #8 received at 41920 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: Jacek Wielemborek <mail <at> d33.pl>, 41920 <at> debbugs.gnu.org
Subject: Re: bug#41920: sort: bug report/feature request: warn is -t is
 effectively a no-op?
Date: Wed, 17 Jun 2020 08:27:27 -0500

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.