Tried using tagged release fish 3.0.2 as well as current master, built from source on Fedora 29, running in Gnome Terminal.
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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.