delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1995/01/10/23:16:03

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

   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....

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

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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019