From: Morten Welinder <terra AT diku DOT dk>
Date: Wed, 11 Jan 1995 10:41:47 +0100
To: turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp
Cc: tim AT pi DOT la DOT tce DOT com, djgpp AT sun DOT soe DOT clarkson DOT edu, opentv AT pi DOT la DOT tce DOT com
Subject: Re: bug in djgpp's make


   Date: Wed, 11 Jan 1995 12:09:23 +0900
   From: Stephen Turnbull <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
   Cc: djgpp AT sun DOT soe DOT clarkson DOT edu, opentv AT pi DOT la DOT tce DOT com

      I just now fetched oak.oakland.edu:/pub/msdos/djgpp/mak371bn.zip and
      verfied that it has the following bug.  If a makefile contains

      foo.o: foo.c
	      asdfasdf < foo.c > foo.o
	      echo hi

      and there is a file named foo.c but no executable named asdfasdf, it
      prints

      asdfasdf < foo.c > foo.o
      Bad command or file name
      echo hi
      hi

      It shouldn't do the echo hi.  Instead, it should stop once an error
      happens.  In general, when there's a DOS command that redirects
      standard input or output in the makefile, and that command gets an
      error, it continues the make, and the error probably goes unnoticed.

   Does this depend on the shell being used?  When DJGPP make encounters
   a redirection or the like, it passes the command line to the shell.  I
   *assume* (but can't verify at the moment, I'm on Linux :) that shells
   (including COMMAND.COM) return a useful exit status, but....

Well, command.com doesn't!  A wrote a version of system() that handles
redirection, so the above might work in V2.

      By the way, the version of make in pub/msdos/gnuish/gmake371.zip on
      oak.oakland.edu doesn't share this bug.

Right, I did some dirty work there...  This version is being
discontinued.  I don't have the time for it, and it would be
better to have DJ's make include the features of it.

   I seem to recall that gnuish make ca. ver. 2.5 used to contain code do
   redirections itself.  That's why I wonder if the secondary shell used
   by DJGPP make is returning a proper exit status.
       --Steve

Morten