On 11/02/10 15:25, Eric Blake wrote:
Pádraig Brady<P<at> draigBrady.com> writes:
I noticed a few more extraneious '.' in --help output
+++ b/src/base64.c
@@ -62,10 +62,9 @@ Base64 encode or decode FILE, or standard input, to
standard output.\n\
\n"), program_name);
fputs (_("\
-w, --wrap=COLS Wrap encoded lines after COLS character (default
76).\n\
- Use 0 to disable line wrapping.\n\
-\n\
- -d, --decode Decode data.\n\
- -i, --ignore-garbage When decoding, ignore non-alphabet characters.\n\
+ Use 0 to disable line wrapping\n\
+ -d, --decode Decode data\n\
+ -i, --ignore-garbage When decoding, ignore non-alphabet characters\n\
We should also patch these to start with lower case (that is:
-d, --decode decode data
rather than Decode data).
Actually there are a few more instance of that (due to me):
$ grep -E " -.* [A-Z]" *.c | grep -v "FILE"
base64.c: -d, --decode Decode data\n\
base64.c: -i, --ignore-garbage When decoding, ignore non-alphabet
characters\n\
base64.c: -w, --wrap=COLS Wrap encoded lines after COLS character
(default 76).\n\
stdbuf.c: -i, --input=MODE Adjust standard input stream buffering\n\
stdbuf.c: -o, --output=MODE Adjust standard output stream buffering\n\
stdbuf.c: -e, --error=MODE Adjust standard error stream buffering\n\
truncate.c: -o, --io-blocks Treat SIZE as number of IO blocks instead
of bytes\n\
It would be nice to have a syntax-check for this, though I
can't think of anything robust enough. Hmm maybe if I grep man/*
I also noticed that there is inconsistent indenting for some --help output.
I'm wary of changing that though as it might add too much churn for translators?
Look at ls --help for example where multiline comments for some options are not
indented.
cheers,
Pádraig.
