[flag] Ignore unknown arguments
Stéphane Bortzmeyer
ignore unknown arguments (instead of saying "flag provided but not
defined"). I plan to parse it manually later.
I cannot find an option in package flag to do so.
roger peppe
unfortunately it's not possible to parse flags without knowing in
advance which flags are valid.
it would be great if you could because that would mean that
the flag package interface could become simpler - no need for the pointers,
and other globals could depend on the value of command-line arguments.
consider the command-line arguments:
-x -y foo
is that
a) a boolean flag "-x" followed by flag "-y" with argument foo ?
b) a flag "-x" with argument "-y" followed by a non-flag argument "foo" ?
c) boolean flags "-x" and "-y" followed by non-flag argument foo ?
what would you like the flag package to do given such an input?
David Roundy
> unfortunately it's not possible to parse flags without knowing in
> advance which flags are valid.
>
> it would be great if you could because that would mean that
> the flag package interface could become simpler - no need for the pointers,
> and other globals could depend on the value of command-line arguments.
>
> consider the command-line arguments:
>
> -x -y foo
>
> is that
> a) a boolean flag "-x" followed by flag "-y" with argument foo ?
> b) a flag "-x" with argument "-y" followed by a non-flag argument "foo" ?
> c) boolean flags "-x" and "-y" followed by non-flag argument foo ?
>
> what would you like the flag package to do given such an input?
You could follow the behavior of getopt, which requires the "="
version to provide an argument that begins with a dash. I wish that
the flag package did try to follow existing argument-parsing
conventions rather than inventing its own.
--
David Roundy
Russ Cox
> version to provide an argument that begins with a dash.
Not true.
$ echo hello | grep -n --label --foo . - /dev/null
--foo:1:hello
$
Russ
Rob 'Commander' Pike
It follows conventions known to the author. As has been said before,
that's the nice thing about standards -- there are so many to choose
from.
-rob
David Roundy
I stand corrected. That's what I get for spouting off without
actually testing...
--
David Roundy
Giles Lean
> It follows conventions known to the author. As has been said before,
> that's the nice thing about standards -- there are so many to choose
> from.
>
> -rob
Not knowing those conventions:
a) can the flag package share where the adopted convention came from,
preferably with a pointer to the rationale?
b) would it do violence to those conventions to allow concatenation of
boolean options?
e.g. In a getopt(3) [non GNU, AT&T, historical :-] world, one types:
$ ls -ld ...
In a Go world using the flag package, one has to type:
$ ls -l -d ...
As the code change to allow concatenation is simple (I built a proof
of concept, and it was almost trivial) I'm assuming the original
behaviour was chosen on purpose.
Providing any change gives precedence to a boolean "ld" option over -l
and -d, the backward incompatibilities I see is that if a programmer
adds a "ld" option where -l and -d already exist, then:
a) if "ld" is boolean, there is a silent runtime change (bad,
admittedly, but so is the choice to have "ld" as an option when -l and
-d already exist, I would argue)
b) if "ld" is not a boolean, and isn't followed by an argument, then
an error message and usage message will be output
c) if "id" is not a boolean and is the last option *and* is followed
by a non-option argument, then that argument is used as the value for
"ld" instead of an an argument. This is the worst case IMHO.
Thoughts?
Giles
P.S. I'd intended to start a new thread to propose this change, but
since discussion in this thread is not just about the existing
behaviour of flag but how it came to be, I hope I'm not so far off the
original topic as to be hijacking the thread. Anyone should feel free
to take responses to a new thread if that makes them more comfortable.
Russ Cox
Russ