In my RFC I dubbed them (&& and ||) the pipeline chain operators because you use them to chain syntactic pipelines together conditionally. The POSIX shell spec

In my RFC I dubbed them (&& and ||) the pipeline chain operators because you use them to chain syntactic pipelines together conditionally. The POSIX shell spec calls them AND-OR lists, which I didn’t think was as descriptive. To explain the pipeline idea a bit better, there are two ways of seeing a pipeline (in PowerShell or in a POSIX shell). One is at runtime; a command executes, taking its input from an input and spitting it out to an output. Chain a few commands together hooking the output of one to the input of another and you have a pipeline. (In POSIX shells of course these in/out locations are file descriptors, whereas in PowerShell they’re memory locations.) But also a pipeline can refer to the syntax of a pipeline; something like `ls | grep “* .txt”` is a pipeline in terms of the POSIX shell grammar. Similarly in PowerShell, `gci | ? Name -like “* .txt”` is a pipeline syntax. And since you can chain these pipelines together with && and ||, I called the operators “pipeline chain operators”. BTW, if you ever want to look at the abstract syntax tree of a PowerShell command, it’s very easy to do by wrapping it in a scriptblock and grabbing its AST: $ast = { gi file.txt && rm file.txt }.Ast $ast.EndBlock.Statements[0]