Bug 3132 - (int-90925) Busybox 1.6.1 "sort -k" only sorts the first field
(int-90925)
: Busybox 1.6.1 "sort -k" only sorts the first field
Status: RESOLVED FIXED
Product: Core
Busybox
: 4.0
: N810 Maemo
: Low normal (vote)
: 5.0-alpha
Assigned To: unassigned
: busybox-bugs
:
:
:
:
  Show dependency tree
 
Reported: 2008-05-04 01:16 UTC by Neil MacLeod
Modified: 2009-03-02 13:36 UTC (History)
2 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Neil MacLeod (reporter) maemo.org 2008-05-04 01:16:33 UTC
SOFTWARE VERSION:
N810, 2.2007.50-2

STEPS TO REPRODUCE THE PROBLEM:

~/tst $ ls -la foo
-rw-r--r--    1 user     users          36 May  3 23:08 foo
~/tst $ cat foo
CCCCCC 2
AAAAAA 1
BBBBBB 4
DDDDDD 6
~/tst $ for n in 1 2; do echo busybox $n; busybox sort -n -k$n foo; done
busybox 1
AAAAAA 1
BBBBBB 4
CCCCCC 2
DDDDDD 6
busybox 2
AAAAAA 1
BBBBBB 4
CCCCCC 2
DDDDDD 6

In Busybox 1.6.1 (and also 1.4.1 - see bug #1637 comment #9 where I first
raised this issue) on N810/N800, the -k parameter is always interpreted as
applying to the first field even when the user wishes to sort on the second
field.

The -k parameter and sorting on fields onther than the first/default field
should be fully supported in all recent versions of busybox.

EXPECTED OUTCOME:

From Ubuntu Feisty Fawn "sort" command:

neil@nm-tyan:~$ uname -a
Linux nm-tyan 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686
GNU/Linux
neil@nm-tyan:~$ which sort
/usr/bin/sort
neil@nm-tyan:~$ for n in 1 2; do echo sort $n; sort -n -k$n foo;done
sort 1
AAAAAA 1
BBBBBB 4
CCCCCC 2
DDDDDD 6
sort 2
AAAAAA 1
CCCCCC 2
BBBBBB 4
DDDDDD 6

ACTUAL OUTCOME:

busybox only ever sorts on the first field even when instructed to sort on the
second, third etc. field. Consequently the following list is NOT correctly
sorted on the second field:

busybox 2
AAAAAA 1
BBBBBB 4
CCCCCC 2
DDDDDD 6

The following Busybox bug suggests that sorting on fields other than the
first/default field is supported: http://bugs.busybox.net/view.php?id=1144 

REPRODUCIBILITY:
always

EXTRA SOFTWARE INSTALLED:

openssh-server, canola

OTHER COMMENTS:
Comment 1 Jianjun Yu 2008-07-18 04:11:19 UTC
I reproduce this bug on my n810.
I am going to fix it.
Comment 2 Eero Tamminen nokia 2008-10-27 11:30:49 UTC
Thanks for the test-case & links!

> The following Busybox bug suggests that sorting on fields other than
> the first/default field is supported: http://bugs.busybox.net/view.php?id=1144

Diablo has Busybox v1.6. Based on the dates in the above upstream bug, the fix
should have gone to Busybox v1.7 or v1.8.  However, when I tested with Busybox
1.10 in Fremantle, it still exhibited this issue.

And when testing this more, none of:
- using letters (and no -n) instead of numbers,
- putting the letter to second char column, or
- using TAB instead of space
helps.  Busybox sort -k option doesn't do anything. Etch Busybox v1.1.3 worked
fine.

Then I started to look into Busybox 1.10 sources. In our version
CONFIG_FEATURE_SORT_BIG isn't currently enabled.  *Keys and -k work only if
it's enabled*.


This is the most annoying thing in Busybox.  If you configure out features, it
doesn't disable the corresponding command line options, it just silently
ignores them (in "ps" case, it ignores all options).  This means that when e.g.
building software using BB, Busybox can just silently corrupt the generated
data; when installing software, installation scripts that given Busybox
configuration breaks, don't fail as they should etc.

Andre, could you file a bug about this to the Busybox Bugzilla (Disabling
features not disabling corresponding command line options and Buggybox not
erroring on unknown options)?
Comment 3 Andre Klapper maemo.org 2008-10-27 13:43:17 UTC
Filed upstream as http://busybox.net/bugs/view.php?id=5764 .
Comment 4 Andre Klapper maemo.org 2008-10-30 12:37:35 UTC
This has been fixed internally and the fix will be included in Fremantle, hence
closing as FIXED.


*** Forwarding comment from the upstream ticket: ***

Works in current svn:

# for n in 1 2; do echo ./busybox $n; ./busybox sort -n -k$n foo; done
./busybox 1
AAAAAA 1
BBBBBB 4
CCCCCC 2
DDDDDD 6
./busybox 2
AAAAAA 1
CCCCCC 2
BBBBBB 4
DDDDDD 6

GNU sort does exactly the same:

# for n in 1 2; do echo $n; sort -n -k$n foo; done
1
AAAAAA 1
BBBBBB 4
CCCCCC 2
DDDDDD 6
2
AAAAAA 1
CCCCCC 2
BBBBBB 4
DDDDDD 6


> Then I started to look into Busybox 1.10 sources. In our version
> CONFIG_FEATURE_SORT_BIG isn't currently enabled. *Keys and -k work
> only if it's enabled*.

D'oh. You disabled the feature and then complain that it doesn't work.

>This is the most annoying thing in Busybox. If you configure out features,
>it doesn't disable the corresponding command line options,
>it just silently ignores them (in "ps" case, it ignores all options).

The opposite behavior would just annoy different group of people, which prefers
utilities to ignore some switches instead of bombing out. umount ignores -v
(verbose) switch. Do you want it to die instead? How is that useful?

> This means that when e.g. building software using BB, Busybox can just
> silently corrupt the generated data

D'oh again. If you plan to build software on the machine you install busybox
on, you'd better enable most of the options, since you want maximum
compatibility. Disabling options implies that you know that in this particular
installation it's ok.
Comment 5 Eero Tamminen nokia 2008-10-30 17:22:59 UTC
(In reply to comment #4)
> > Then I started to look into Busybox 1.10 sources. In our version
> > CONFIG_FEATURE_SORT_BIG isn't currently enabled. *Keys and -k work
> > only if it's enabled*.
> 
> D'oh. You disabled the feature and then complain that it doesn't work.

I couldn't comment on the bug as it was closed (thanks for filing it!), so I
filed a new one which I formulated a bit better:
http://busybox.net/bugs/view.php?id=5864

(I guess I should have done that in the first place.)