Pádraig Brady wrote: > Davide Canova wrote: >> $ sort -k 1b,1b #1 >> a x >> a y >> a z >> ^D >> a z >> a y >> a x >> >> $ sort -k 1b,1.0b #2 >> a x >> a y >> a z >> ^D >> a x >> a y >> a z > > I'm confused by the first command output too. > I'm not sure what the code is trying to do. > It looks like if you do specify and end field, > but don't specify the .# part of it (as in the first > example above), it bumps the end field up one? > The line of code doing that is: http://url.ie/141l > That in conjunction with skipping "ending blanks" > is causing the issue I think.
I've looked at this a little more, and wow it's confusing. I think the documentation is inconsistent at least wrt -kPOS1,POS2.C For POS2.0 it says that it refers to the end of POS2 field. In fact what the code seems to be doing is referring to the end of field, POS2 - 1. This is demonstrated like: $ cat sort.test2 a a b z a a $ ./sort-dbg -k2b,3b sort.test2 #eword=3 here z a a a a b $ ./sort-dbg -k2b,3.0b sort.test2 #eword=2 here a a b z a a Now one should never need to specify .0 so it seems to me that it's an implementation detail that's leaked (incorrectly) into the documentation? I don't know what's going on exactly thought as as I don't know what's expected. It certainly seems buggy. The limfield function seems suspicious at least: hyyp://url.ie/15a7 Can someone at least confirm that we (should) interpret the "a x" input as having 2 fields, 'a' and ' x' ? cheers, Pádraig. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils