As discovered on matrix/gitter:
is seen as syntactically valid, but doesn't do anything sensible. The backgrounded command doesn't set $status and so the && reacts to the previous $status - execute false before and disown won't be executed.
As a test:
false
sleep 10 & && echo foo
won't print foo, but replace "false" with "true" and it will.
Conceptually this also makes no sense - you can't react to the status of a backgrounded command like that because it doesn't have a status once the next command is executed.
So the only sensible thing to do here is to make it an error, like it already is for and:
prints
fish: The “and” command can not be used immediately after a backgrounded job
sleep 10 & and echo foo
^~^
As discovered on matrix/gitter:
is seen as syntactically valid, but doesn't do anything sensible. The backgrounded command doesn't set $status and so the
&&reacts to the previous $status - executefalsebefore anddisownwon't be executed.As a test:
won't print foo, but replace "false" with "true" and it will.
Conceptually this also makes no sense - you can't react to the status of a backgrounded command like that because it doesn't have a status once the next command is executed.
So the only sensible thing to do here is to make it an error, like it already is for
and:prints