Currently, when there is no FILE argument following a switch such
as -man, -rst, or -none, kernel-doc exits with a warning from perl
(long msg folded):
Use of uninitialized value $ARGV[0] in pattern match (m//)
at ./scripts/kernel-doc line 438.
, which is unhelpful.
Improve the behavior by adding a check at the bottom of parsing
loop.
If the argument is absent, display help text and exit with
the code of 1 (via usage()).
Signed-off-by: Akira Yokosawa <[email protected]>
Cc: Jonathan Corbet <[email protected]>
Cc: Tomasz Warniełło <[email protected]>
Cc: Randy Dunlap <[email protected]>
Cc: [email protected]
Cc: [email protected]
---
Changes since v1 [1]:
- No code change
- Amend subject and reword the whole changelog.
- The message from perl is not an error but a warning.
(I thank Tomasz for pointing it out.)
I thought the change of exit code might affect sphinx-build processing,
and tested with several runs of "make htmldocs" and "make pdfdocs".
So far, I've not seen any regression.
[1] v1: https://lore.kernel.org/r/[email protected]
Thanks, Akira
--
scripts/kernel-doc | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/scripts/kernel-doc b/scripts/kernel-doc
index 3106b7536b89..faefe2977f0e 100755
--- a/scripts/kernel-doc
+++ b/scripts/kernel-doc
@@ -494,7 +494,11 @@ while ($ARGV[0] =~ m/^--?(.*)/) {
}
} else {
# Unknown argument
- usage();
+ usage();
+ }
+ if ($#ARGV < 0){
+ print "No FILE!\n";
+ usage();
}
}
base-commit: b62ef3a1cca0553613adce16515f3640400725b4
--
2.17.1
Akira Yokosawa <[email protected]> writes:
> Currently, when there is no FILE argument following a switch such
> as -man, -rst, or -none, kernel-doc exits with a warning from perl
> (long msg folded):
>
> Use of uninitialized value $ARGV[0] in pattern match (m//)
> at ./scripts/kernel-doc line 438.
>
> , which is unhelpful.
>
> Improve the behavior by adding a check at the bottom of parsing
> loop.
> If the argument is absent, display help text and exit with
> the code of 1 (via usage()).
As might be expected, this applied poorly after the pod patches went in.
I went ahead and resolved the conflict, substituting an appropriate
pod2usage() call.
Thanks,
jon