Pádraig Brady wrote:
...
> 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/*
Good idea.
Here's a first cut.
It would have to search only .c files.
This one currently ignores 2nd and subsequent lines of
multi-line descriptions.
# This spots a capital on a short-only line (currently only one false positive)
git grep -E '^ {0,7}-\w( ?[^ ]+)? *[A-Z][a-z]'
# This matches lines with a long option and optional preceding short option:
git grep -E '^ {0,7}(-\w( ?[^ ]+)?, )?--[^ ]* *[A-Z][a-z]'
NEWS: --indicator-style=slash. Use --file-type or
src/base64.c: -d, --decode Decode data\n\
src/base64.c: -i, --ignore-garbage When decoding, ignore non-alphabet
characters\n\
src/base64.c: -w, --wrap=COLS Wrap encoded lines after COLS character
(default 76).\n\
src/pr.c: -D FORMAT, --date-format=FORMAT Use FORMAT for the header date.
src/stdbuf.c: -i, --input=MODE Adjust standard input stream buffering\n\
src/stdbuf.c: -o, --output=MODE Adjust standard output stream buffering\n\
src/stdbuf.c: -e, --error=MODE Adjust standard error stream buffering\n\
src/stty.c: -a, --all Write all current settings to stdout in
human-readable form.
src/stty.c: -g, --save Write all current settings to stdout in
stty-readable form.
src/stty.c: -F, --file Open and use the specified device instead of stdin
src/truncate.c: -o, --io-blocks Treat SIZE as number of IO blocks
instead of bytes\n\
> 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.
It might not matter if xgettext's fuzzy matcher can compensate.
But then maybe it's not worth changing, either.
