bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#44248: Indentation of --help and --version


From: Pádraig Brady
Subject: bug#44248: Indentation of --help and --version
Date: Tue, 27 Oct 2020 14:15:03 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:82.0) Gecko/20100101 Thunderbird/82.0

On 27/10/2020 02:19, Paul Eggert wrote:
One way to attack the problem is (1) use only one-liners for option help, and
(2) not worry about indentation so much (either in English or in German) as the
excess indenting doesn't help readability enough to justify the translation
hassle. To do that, I propose changes like the attached for comm. This will
cause 'comm --help' output to look like the following, which is good enough and
which will still work with help2man:

Usage: comm [OPTION]... FILE1 FILE2
Compare sorted files FILE1 and FILE2 line by line.

When FILE1 or FILE2 (not both) is -, read standard input.

With no options, produce three-column output.  Column one contains
lines unique to FILE1, column two contains lines unique to FILE2,
and column three contains lines common to both files.

    -1  suppress column 1 (lines unique to FILE1)
    -2  suppress column 2 (lines unique to FILE2)
    -3  suppress column 3 (lines that appear in both files)

    --check-order  check that the input is correctly sorted
    --nocheck-order  do not check that the input is correctly sorted
    --output-delimiter=STR  separate columns with STR
    --total  output a summary
    -z, --zero-terminated  line delimiter is NUL, not newline
        --help     display this help and exit
        --version  output version information and exit

Note, comparisons honor the rules specified by 'LC_COLLATE'.

Examples:
    comm -12 file1 file2  Print only lines present in both file1 and file2.
    comm -3 file1 file2  Print lines in file1 not in file2, and vice versa.

I feel using only one liners for all utils would lose too much information.

I feel less strongly about removing indentation,
though do feel we would lose reability.
Consider `ls --help` for example.
comm --help is already quite unreadable and so less
affected by such changes.

Also a mass change like this could invalidate existing translations,
and cause too much churn.

We did discuss a long time ago that a mass change
to warrant the churn would be to split each
option to a separate string, i.e. a separate translation.
Also that we could take advantage of the mbsalign module
to more dynamically align the option description.


cheers,
Pádraig





reply via email to

[Prev in Thread] Current Thread [Next in Thread]