Re: Sort order bug in GNU sort

[Luke Hutchison]

On Thu, Oct 29, 2009 at 8:28 PM, Luke Hutchison <address@hidden> wrote:
> On Thu, Oct 29, 2009 at 7:53 PM, Eric Blake <address@hidden> wrote:
>>> Could the manpage please be extended to give a simple example
>>> comparing the sort order in the en_US locale with the C locale, to
>>> make this much clearer?
>>
>> The man page comes from 'sort --help', and both try to be as concise as
>> possible.  But the info pages would be a reasonable place to add another
>> example, if it would help make it obvious what consequences are associated
>> with alternate locales.  Would you like to try your hand at writing the
>> patch, or at least propose the wording to use?
>
> I understand that --help output needs to be relatively short,
> nevertheless adding a short example will probably save lots of similar
> questions on the mailing lists if the FAQ is correct in stating how
> frequently this question is raised.

I also submit another suggested change for consideration:

Original:

    -k, --key=POS1[,POS2]
         start a key at POS1 (origin 1), end it at POS2 (default end of line)

 Suggested change:

    -k, --key=POS1[,POS2]
         start a key at POS1 (origin 1), end it at POS2 (default end of line);
         if no key specified, the whole input line is used as the key

Reasoning for needing this additional wording: as mentioned in a
previous email, the following text made me think sort used
blank/non-blank field-based sorting if no delimiter character was
given, and in fact the exact opposite is true in en_US, where blanks
are ignored entirely:

    -t, --field-separator=SEP
          use SEP instead of non-blank to blank transition

Thanks.