Subject: Re: How make(1) reacts on failing commands
To: Roland Illig <>
From: Eric Haszlakiewicz <>
List: tech-pkg
Date: 11/17/2005 13:16:09
On Thu, Nov 17, 2005 at 06:57:31PM +0100, Roland Illig wrote:
> foo:
>         echo foo
>         false
>         echo bar
>         set -o
> "echo bar" and "set -o" would not be executed (with the default options; 
> there's still -k).

Of course.  That's the normal behavior that everyone expects from make.
From the shell, on the other hand, I at least don't expect "false" to be
the same as "exit". :)

> >Is this something that has changed recently?  If it really is supposed to
> >work how you say it is, how can one ever use make to run a program that
> >doesn't return 0?  (e.g. even just a simple rv=`cmp -s a b` would cause
> >the script line to stop)
> Surround it with "if". See mk/bulk/print{index,depends} for examples. I 
> have rewritten them lately to use the "set -e" mode. (printindex, line 
> 157--158, is a good starting point.)

	oh, I think I see what's happening.  The assignment of a variable
has an exit status equal to the last thing that is run as part of calculating
the value to set.  So this:
	foo=`echo foo; false; echo bar`
will actually work and foo ends up set to "foo\nbar".  IMO the behavior
of "set -e", esp. wrt variable assignment is far from the "least surprise"
ideal, but whatever.

So, I'm going to change that line in do-fetch to read:
	vul=`${MAKE} ${MAKEFLAGS} check-vulnerable || ${TRUE}`;        \
which should allow it to continue with the rest of the script.
I was wondering why you don't run into problems like this all over
the place, but I now see that there are thinks like "... || ${TRUE}"
all over the place also.