Re: Bug in $(shell ...) I can't understand

[Dmitry V. Levin]

On Sun, Feb 06, 2022 at 03:21:39PM -0500, Paul Smith wrote:
> On Sun, 2022-02-06 at 20:18 +0300, Dmitry V. Levin wrote:
> > 4175643 write(2<pipe:[1062668627]>, "/bin/sh: bad-program: command no"..., 
> > 40) = 40
> > 4175640 <... read resumed>"/bin/sh: bad-program: command no"..., 200) = 40
> > 4175640 read(5<pipe:[1062668627]>,  <unfinished ...>
> > 4175643 +++ exited with 127 +++
> > 4175640 <... read resumed>"", 160)      = 0
> > 4175642 +++ exited with 127 +++
> > 4175640 write(2</dev/null>, "/bin/sh: bad-program: command no"..., 40) = 40
> > 4175640 write(1</dev/null>, "out = ", 6) = 6
> > 4175640 write(1</dev/null>, "\n", 1)    = 1
> > 4175640 read(4</tmp/Makefile>, "", 4096) = 0
> > 4175640 write(2</dev/null>, "make: *** No targets.  Stop.\n", 29) = 29
> > 4175640 +++ exited with 2 +++
> 
> Yes, I saw this as well.  But this doesn't help me understand WHY it's
> happening.  There's something make is doing here that's causing this
> but I don't understand what it is.  Make is reading the output of the
> pipe, like we want, but somehow it's then rewriting the output to its
> own stderr... why is that happening?
> 
> Oh.  I see the problem.  If the shell exits with an exit code of 127
> then make's shell function assumes that it failed because the sub-
> process was not found, and it actually writes its output to stderr!!

Sorry if my examples were not clear enough.
Yes, it's the exit status that makes all the difference.


-- 
ldv