test: Show error when using a binary operator without two operands

[sargas]

When preforming a binary operation with the test command, GNU coreutils gives an error if only one operands exist:

$ /bin/test -o blah
/bin/test: ‘-o’: unary operator expected
$ /bin/test -a blah
/bin/test: ‘-a’: unary operator expected

$ /bin/test blah -a
/bin/test: missing argument after ‘-a’
$ /bin/test blah -o
/bin/test: missing argument after ‘-o’

This PR adds the error messages for the first set, where the first operand is missing. The second operand missing does not appear as trivial, since Symbol::new causes the operator to be treated as a literal as part of the parsing.

With this PR, tests/test/test-diag.pl should pass.

This PR also fixes an integration test that says that -a ! should return an exit code of 1. GNU test gives an error with a status code of 2.

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/tail/inotify-dir-recreate (passes in this run but fails in the 'main' branch)
Congrats! The gnu test tests/test/test-diag is no longer failing!

[sylvestre]

could you please add a check of the string ? thanks

[sylvestre]

ping ? :)

[tertsdiepraam]

@sargas

The second operand missing does not appear as trivial, since Symbol::new causes the operator to be treated as a literal as part of the parsing.

This should still be done right? Should we open an issue for it in meantime?

[sargas]

@sargas

The second operand missing does not appear as trivial, since Symbol::new causes the operator to be treated as a literal as part of the parsing.

This should still be done right? Should we open an issue for it in meantime?

Agreed, especially since the GNU tests didn't check for this. I can have a go at this tonight

[sylvestre]

@sargas ping ? :)

[BenWiederhake]

Thank you! Yes, this PR fixes the GNU test, but just shifts the problem in an unfixable way, because after parse() has finished, important information is lost.

Can the error be detected during parse()?

[BenWiederhake]

This works on the top-level, yes, but does not work if there are preceding expressions, e.g. test foo -a ( -o bar ).

In fact, this cannot work, since the information is lost after parse() is finished, and your code raises the error only later in eval. See #6203 for more examples.

Therefore, the error handling must happen during parse(), and doing it in eval() would only make it even harder to get it right.

[sargas]

Woah, thank you for the detailed explanation in that issue. I'll take a look at how the parsing is done to see what's simple to change and watch the other issue for updates.

[sargas]

Wanted to leave an update on this: I looked into using nom and pest for an easier to update grammar, and starting implementing the grammar in pest, but this was an awkward approach. test operates on a vector, while parsers usually operate on strings or something tokenized. Still trying things out, but wanted to relay I'm still interested in this

[sargas]

@sargas ping ? :)

Sorry, busier than expected, still interested in this PR. Whether <blah> -a shows an error is different for an arbitrary string and for !, so I wanted to create some more test cases

[github-actions]

GNU testsuite comparison:

Congrats! The gnu test tests/test/test-diag is no longer failing!