Bash – Logical AND in a bash script

This is a job for expect.

Lets say your C program outputs something similar to the following:

question 1? (y/n):
question 2? (y/n):
enter some percent value:
bunch of stuff
confirm? (y/n):

You would write an expect script such as:

#!/usr/bin/expect

foreach file [glob /path/to/70k/files/*] {
  spawn "/path/to/c_prog" $file

  expect "question 1? (y/n): " { send "y\r" }
  expect "question 2? (y/n): " { send "n\r" }
  expect "enter some percent value: " { send "100\r" }
  expect "confirm? (y/n): " { send "y\r" }
  interact
}

Then either chmod +x the script and run it, or expect /path/to/script

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.