fix: --long= should not consume the next argument

[telemachus]

[telemachus]

I added a couple of tests to confirm that (1) for a boolean, --long= parses as true, (2) for other flags --long= parses as --long="", and (3) --long= does not consume the next argument from args.

In the parsing code, I tried to minimize changes, but while I was there I updated two comments to reflect that only long flags were at issue, and I changed len(args) <= 0 to len(args) == 0 since I don't think it's ever possible for a slice to have a negative length.

I considered adding a further test (like below) for --long="" with non-string flags, but I wasn't sure whether testing for such a specific error was too fiddly. Let me know if you think more tests are needed.

{
	Name:         "--flt= -a",
	Constructors: []fftest.Constructor{fftest.CoreConstructor},
	Args:         []string{`--flt=`, `-a`},
	Want:         fftest.Vars{WantParseErrorIs: strconv.ErrSyntax},
},

[telemachus]

@tgulacsi I appreciate the support, but I think we just have to wait for the maintainer to get a chance to review the changes and decide what he wants to do. I don't think that outside people approving will make much a difference one way or the other. (Though, that said, I'm happy for the code review!)

[cbandy]

While reading the conversations around this, I'm unsure if everyone understands what the shell does with quotes before the Go program receives anything.

For example, this is one argument (word) on the command line that contains no quotes: 'asdf'qqq"xyz"''""''gg

This is a small script that prints each of its arguments on a separate line. With it in args.sh plus chmod +x args.sh, the above looks like this:

#!/bin/sh
printf "|%s|\n" "$@"

$ ./args.sh 'asdf'qqq"xyz"''""''gg
|asdfqqqxyzgg|

There are no quotes for Go to parse in the following, either. Notice that:

• -config "" arrives as two arguments, 7 bytes then 0 bytes.
• -config="" arrives as one argument, 8 bytes ending with =.

$ ./args.sh -config=foo -config foo -config "" -config="" -config -config=
|-config=foo|
|-config|
|foo|
|-config|
||
|-config=|
|-config|
|-config=|

[telemachus]

@cbandy I think I understand your point, but to be clear, do you think that affects the main fix here? That is, even given what you show, I think it's a bug for ff to attach a subsequent argument to --long=. To put this another way, regardless of how the shell handles empty strings and quotes, I don't think that ff should treat []string["--long=", "foo"] as if it were []string["--long=foo"]. Do you think I'm wrong?

[cbandy]

I don't think that ff should treat []string["--long=", "foo"] as if it were []string["--long=foo"].

Agreed.