Austin Group Defect Tracker

Aardvark Mark IV


Viewing Issue Simple Details Jump to Notes ] Issue History ] Print ]
ID Category Severity Type Date Submitted Last Update
0000510 [1003.1(2008)/Issue 7] Shell and Utilities Objection Omission 2011-11-16 18:15 2019-06-10 08:55
Reporter eblake View Status public  
Assigned To ajosey
Priority normal Resolution Accepted  
Status Closed  
Name Eric Blake
Organization Red Hat
User Reference ebb.sort
Section sort
Page Number 3184
Line Number 106060
Interp Status ---
Final Accepted Text
Summary 0000510: sort -k should allow more than one modifier in [type]
Description A strict reading of sort -k 'keydef' says that each optional 'type'
is a single modifier. But there are cases where it is desirable to
have more than one modifier in a -k listing. Consider a file containing:

 1b1 b
2a2 b
3a3 a

In the POSIX locale, this file is correctly sorted under the
specification of a primary key being the second non-blank character of
field 1 in reverse order, and a secondary key of the second field
including blanks in normal order. But the only way to express this as
a sort command line is to use multiple types on either the start or the
end field of key 1; use of a global -b or -r would break the sorting
desired of the secondary key. That is, there is no alternative to this
command line:

printf ' 1b1 b\n2a2 b\n3a3 a\n' | LC_ALL=C sort -k1.2b,1.2rb -k2,2

which would result in the same output, but without using a [type] of rb
in at least one of the two positions of the first -k option.

My testing shows that GNU, Solaris, BSD, AIX, HP-UX, and IRIX sort all
support the above use of multiple letters for type, so this proposal
should not be very controversial.
Desired Action At line 106060 [XCU sort OPTIONS], change "type is a modifier from the list"
to "type is one or more modifiers from the list".
Tags tc2-2008
Attached Files

- Relationships

-  Notes
(0001093)
Don Cragun (manager)
2012-01-13 22:58
edited on: 2012-04-13 07:44

An alternative fix for this problem would be to change P3184, L106058 from:
    field_start[type][,field_end[type]]
to:
    field_start[type...][,field_end[type...]]

(0001094)
nick (manager)
2012-01-14 01:49

If we go with the [type...] approach suggested by Don, we would also need to make the same change on P3185 line 106120.
(0001242)
Don Cragun (manager)
2012-05-24 16:14

The suggestion in the notes was discussed, but rejected because the utility syntax guidelines don't clearly allow ... to be used in option-arguements; only in operands.

- Issue History
Date Modified Username Field Change
2011-11-16 18:15 eblake New Issue
2011-11-16 18:15 eblake Status New => Under Review
2011-11-16 18:15 eblake Assigned To => ajosey
2011-11-16 18:15 eblake Name => Eric Blake
2011-11-16 18:15 eblake Organization => Red Hat
2011-11-16 18:15 eblake User Reference => ebb.sort
2011-11-16 18:15 eblake Section => sort
2011-11-16 18:15 eblake Page Number => 3184
2011-11-16 18:15 eblake Line Number => 106060
2011-11-16 18:15 eblake Interp Status => ---
2012-01-13 22:58 Don Cragun Note Added: 0001093
2012-01-14 01:49 nick Note Added: 0001094
2012-04-13 07:44 Don Cragun Note Edited: 0001093
2012-05-24 16:14 Don Cragun Note Added: 0001242
2012-05-24 16:14 Don Cragun Status Under Review => Resolved
2012-05-24 16:14 Don Cragun Resolution Open => Accepted
2012-05-24 16:14 Don Cragun Tag Attached: tc2-2008
2019-06-10 08:55 agadmin Status Resolved => Closed


Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker