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
