Thus spake Robert Elz ("RE> ") sometime Tomorrow...

RE> Then how would you handle a Makefile that happened to contain
RE>
RE> 	(cd dir && test -f file && cat file)

1.  prepend the command with a '-';
2.  put it within if/then/fi;

RE>
RE> If file doesn't exist, that will exit 1, as the last command
RE> executed is te test, which failed (same if dir doesn't exist).

According to rules of sh and make, if that's what you want to do,
that's not the right way to go about it.

RE> But that isn't what is wanted - the intent there is simply to cat
RE> the file, if it exists, and do nothing if it doesn't.

	(cd dir && test -f file && cat file) || :;

RE> This is why the && exception exists in the rules - nothing else makes
RE> sense.   How can doing it in a sub-shell (needed so the cd doesn't
RE> change the parent shell) possibly be intended to change the result?
RE> That makes no sense.

But the result has always been passed back.  I'm querulous as to why &&
is actually in there; it doesn't need an exception since if the lhs fails,
everything else after the && of the failed lhs is not going to get executed
anyway, and a failed lhs of a && causes the entire logic string to
be evaluated as an error.  Having || as the exception makes sense,
seeing as if the -e were applied to the lhs of a ||, the rhs would never
be run, as it depends on the lhs having failed in the first place.

				--*greywolf;
--
NetBSD: The Power of Code.