Mixing the && and || operators with "and"/"or" does not behave

[Phidica]

Tried using tagged release fish 3.0.2 as well as current master, built from source on Fedora 29, running in Gnome Terminal.

Problem

The command true && and true sets the exit code to 1 but is otherwise not indicated to be misbehaving.

Changing the command to true && and echo word reveals that the final statement is never executed (nothing is printed). Running true && and exits with code 2 instead and prints the help information for and. Running true && or exits with code 2 and prints the help info for or.

Similar results are observed with ||. false || and and false || or exit with code 2 and print the help info for and or or.

In all these cases, a command placed after the and or or is never executed.

Expected behaviour

I think that these two constructs shouldn't be allowed to be mixed in this way, as the results are unintuitive. The parser should expressly reject and or or when they follow && or ||, to prevent users accidentally creating structures that don't behave as they may anticipate, with commands that never execute.

[zanchey]

Yeah, that should be a syntax error.

[mqudsi]

Nice catch. It's more generic than that, things like true; and and foo are also accepted but broken.

[Phidica]

Indeed, chaining an arbitrary number of ands together used to be okay in fish 2.7. Now it appears the first is considered an operator, the second a command, and rest are arguments to the command. Naturally, that's broken.

[ridiculousfish]

What's going on here is that and is recognized syntactically at parse time, but also has a double-life as a builtin. and is normally parsed as a "job decorator" but here it's becoming an ordinary command. For example true && and --help will print and's help.

Rejecting and as a command seems smart to me. Nice catch.

Speaking of which and --help is broken, bleh.

[ridiculousfish]

and --help fixed as fa6bac1