Bash – Precedence of Pipe (|) and logical and (&&) in bash

bash

The classic scenario with Operator Precedence, you have a line like : 

(cd ~/screenshots/ && ls screenshot* | head -n 5)

And you don't know if it's parsed ((A && B) | C) or (A && B | C)…

The almost official documentation found here doesn't list the pipe in the list so I cannot simply check in the table.

Furthermore in bash, ( is not only for changing the order of operations but creates a subshell, so I'm not 100% sure this lines is the equivalent of the previous line :

((cd ~/screenshots/ && ls screenshot*) | head -n 5)

More generally, how to know the AST of a bash line? In python I have a function that gives me the tree so that I can easily double check the order of operation.

Best Answer

cd ~/screenshots/ && ls screenshot* | head -n 5

This is equivalent to

cd ~/screenshots && { ls screenshot* | head -n 5 ; }

(the braces group commands together without a subshell). The precedence of | is thus higher (binds tighter) than && and ||. That is,

A && B | C

and

A || B | C

always mean that only B's output is to be given to C. You can use (...) or { ... ; } to join commands together as a single entity for disambiguation if necessary:

{ A && B ; } | C
A && { B | C ; } # This is the default, but you might sometimes want to be explicit

You can test this out using some different commands. If you run

echo hello && echo world | tr a-z A-Z

then you'll get

hello
WORLD

back: tr a-z A-Z upper-cases its input, and you can see that only echo world was piped into it, while echo hello went through on its own.

This is defined in the shell grammar, although not terribly clearly: the and_or production (for &&/||) is defined to have a a pipeline in its body, while pipeline just contains command, which doesn't contain and_or - only the complete_command production can reach and_or, and it only exists at the top level and inside the bodies of structural constructs like functions and loops.

You can manually apply that grammar to get a parse tree for a command, but Bash doesn't provide anything itself. I don't know of any shell that does beyond what's used for their own parsing.

The shell grammar has a lot of special cases defined only semi-formally and it can be quite a mission to get right. Even Bash itself has sometimes gotten it wrong, so the practicalities and the ideal may be different.

There are external parsers that attempt to match the syntax and produce a tree, and of those I will broadly recommend Morbig, which attempts to be the most reliable.

Related Question