On Thu, Oct 29, 2009 at 8:28 PM, Luke Hutchison <[email protected]> wrote:
> On Thu, Oct 29, 2009 at 7:53 PM, Eric Blake <[email protected]> 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.
