Paul,
thanks for replying so swiftly.
Your patch suggests that this behaviour of only inspecting the given
keys is intentional?
I would suggest removing the reference to the equivalence of -u and
uniq althogether then.
Regards,
Joost
>>>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes:
> Subject: Re: sorting with -u and -k
> From: Paul Eggert <[EMAIL PROTECTED]>
> To: Joost Helberg <[EMAIL PROTECTED]>
> Cc: [EMAIL PROTECTED], bug-coreutils@gnu.org
> Date: Thu, 24 Jan 2008 12:32:16 -0800
> Joost Helberg <[EMAIL PROTECTED]> writes:
>> given options '-t: -k2 -k3' the following lines compare equal:
>>
>> foo:1:2
>> oof:1:2
>>
>> hence, the oof-line doesn't appear in case -u was used.
>>
>> This strikes me as a surprise, I expected that these two lines would
>> compare as non-equal. I cannot find any explicit reference in the
>> manual indicating this as correct behaviour (only one example is
>> given: -n).
> Thanks for mentioning this. Here's a proposed fix to the manual
> to explain this more carefully.
> 2008-01-24 Paul Eggert <[EMAIL PROTECTED]>
> * coreutils.texi (sort invocation): -u inspects only specified fields.
> Problem reported by Joost Helberg.
> diff --git a/doc/coreutils.texi b/doc/coreutils.texi
> index 3785eae..3741e5d 100644
> --- a/doc/coreutils.texi
> +++ b/doc/coreutils.texi
> @@ -3793,6 +3793,8 @@ this equivalence does not extend to arbitrary
> @command{sort} options.
> For example, @code{sort -n -u} inspects only the value of the initial
> numeric string when checking for uniqueness, whereas @code{sort -n |
> uniq} inspects the entire line. @xref{uniq invocation}.
> +Similarly, @code{sort -k 4,4 -u} inspects only the fourth field when
> +determining whether two lines differ.
> @item -z
> @itemx --zero-terminated
--
Snow B.V. http://snow.nl Tel 0418-653333 Fax 0418-653666
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
