Subject: Re: How make(1) reacts on failing commands
To: Roland Illig <rillig@NetBSD.org>
From: Eric Haszlakiewicz <erh@netbsd.org>
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.
eric