frontend: properly handle option processing

this means that the usage goes from:
 lb {-h|--help|-u|--usage|-v|--version}
 lb COMMAND [OPTIONS]

to:
 lb {-h|--help|-u|--usage|-v|--version}
 lb [FRONTEND_OPTIONS] COMMAND [COMMAND_OPTIONS]

though it is probably not worth is to update the description in the
manpages...? hmm...

so for instance this matters for color control with --color|--no-color
(you already had full control via environment vars). previously you could
do `lb COMMAND --no-color` to turn off colour, only to find that output
at the frontend level was still coloured (the option is processed at the
command context level, not the frontend), so you might try to instead use
`lb --no-color COMMAND`, only to find that this was not supported. Well
now it is, and used at the frontend level will fully control colour output
(after the command is processed anyway).

the full set of common options are thus available (except --force) at the
frontend level, and thus for instance all Echo_*() helpers used in the
frontend will work correctly after args are processed.

furthermore usage like `lb --color --help` will actually work. (not that
color is used there, but this previously would have failed with the
frontend treating the `--color` argument as the command; that's the point!)

Gbp-Dch: Short

1 files changed, 1 insertions, 1 deletions

diff --git a/scripts/build/config b/scripts/build/config
index 05239eae6..9805e2af0 100755
--- a/scripts/build/config
+++ b/scripts/build/config
@@ -179,7 +179,7 @@ Local_arguments ()
 	ARGUMENTS="$(getopt --longoptions ${LONG_OPTIONS} --name="${PROGRAM}" --options a:d:m:k:b:s:c:huv --shell sh -- "${@}")" || ERR=$?
 
 	if [ $ERR -eq 1 ]; then
-		Echo_error "invalid arguments"
+		Echo_error "Invalid argument(s)"
 		exit 1
 	elif [ $ERR -ne 0 ]; then
 		Echo_error "getopt failure"