Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site rlgvax.UUCP
Path: utzoo!watmath!clyde!bonnie!akgua!mcnc!decvax!linus!philabs!cmcl2!seismo!rlgvax!guy
From: guy@rlgvax.UUCP (Guy Harris)
Newsgroups: net.bugs.usg,net.unix-wizards
Subject: Re: Make bug
Message-ID: <485@rlgvax.UUCP>
Date: Thu, 14-Feb-85 21:43:41 EST
Article-I.D.: rlgvax.485
Posted: Thu Feb 14 21:43:41 1985
Date-Received: Sun, 17-Feb-85 05:49:27 EST
References: <305@ist.UUCP> <284@mtxinu.UUCP>
Organization: CCI Office Systems Group, Reston, VA
Lines: 36
Xref: watmath net.bugs.usg:174 net.unix-wizards:12064

> > I recently found the following bug (feature?) in System 3, 5, OSx Make
> > in the following shell script:

...

> I guess it's fixed here!

That's probably because you're on a 4.2BSD system; it doesn't occur
here either.  From an article explaining the bug:

> David Tilbrook, Imperial Software Technology, London England in <305@ist.UUCP>
> points up a bug in make whereby the shell's filename  expansion is suppressed
> when make is invoked:

> 	make -f - < descfile

> rather than:

> 	make -f descfile

> The bug is actually in /bin/sh.  In sh/expand.c around line 112 the shell
> attemps to open a directory to scan for file name expansions:

> 	if ((dirf = open(*s ? s : ".", 0)) > 0)

	...

> The asuumption is that open will never return 0; the check should be >= 0.

In a 4.2BSD version of the shell (any shell), this would be done with
"opendir"; in the process of changing the code to use the directory
library, one would almost certainly fix the bug (since the test would be
against a null pointer return).

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy