sort: fix parsing of end field in obsolescent key formats

This regression was introduced in commit 224a69b5, 2009-02-24,
"sort: Fix two bugs with determining the end of field".
The specific regression being that we include 1 field too many when
an end field is specified using obsolescent key syntax (+POS -POS).

* src/sort.c (struct keyfield): Clarify the description of the eword
member, as suggested by Alan Curry.
(main): When processing obsolescent format key specifications,
normalize eword to a zero based count when no specific end char is given
for an end field. This matches what's done when keys are specified with -k.
* tests/misc/sort: Add a few more tests for the obsolescent key formats,
with test 07i being the particular failure addressed by this change.
* THANKS: Add Alan Curry who precisely identified the issue.
* NEWS: Mention the fix.
Reported by Santiago Rodríguez

1 files changed, 4 insertions, 0 deletions

diff --git a/NEWS b/NEWS
index 867589c52..32ea39211 100644
--- a/NEWS
+++ b/NEWS
@@ -14,6 +14,10 @@ GNU coreutils NEWS                                    -*- outline -*-
   handled correctly, including multi byte locales with the caveat
   that multi byte characters are matched case sensitively.
 
+  sort again handles obsolescent key formats (+POS -POS) correctly.
+  Previously if -POS was specified, 1 field too many was used in the sort.
+  [bug introduced in coreutils-7.2]
+
 ** New features
 
   join now accepts the --header option, to treat the first line of each