Ron Heiby (The Moderator) <unix-request@cbosgd.UUCP> (03/18/85)
Unix Technical Digest Mon, 18 Mar 85 Volume 1 : Issue 28
Today's Topics:
Administrivia
commands within ``make''
Make bug (4 msgs)
Makefiles are for more than just compilations? (2 msgs)
----------------------------------------------------------------------
Date: Mon, 18 Mar 85 04:07:39 GMT
From: Ron Heiby (The Moderator) <unix-request@cbosgd.UUCP>
Subject: Administrivia
I have received a couple of messages suggesting a different use of the
Keywords header line than I have been. First, what I have been doing.
My guess had been that with the variations in Unix out there, that many
people who were running 4bsd would find little of interest in SysV specific
articles and vice versa. So, I have been putting BSD4, BSD4.2, SYSV, etc.
in the "Keywords" line so that people could "n" (or "rn" could kill) any
article directed at a specific audience different from the reader. Likewise,
the usage of NETUNIX to indicate articles originating on the net newsgroups
comes from the same premise. (This digest should have a NETUNIX keyword,
except that I wanted everyone to see this. People who have been following
those groups can skip the other articles in this digest.)
A couple of people have requested that the keywords field be used more for
selection of topics of interest, rather than for elimination of audience.
For example, this digest would have keywords like "Administrivia", "make",
and "efficiency".
I think there is merit to either approach, although I can't think of how
I could combine the two. Also, The second approach will take a bit more
work (no, I don't mind) and will probably not be perfect (see discussions
of K news in the net.news group). So, I put it to the readership. Which
kind of keywords, the first (current) approach or the second approach. It
really doesn't matter much to me. (I read all this stuff, anyway!)
Thanks. Ron.
------------------------------
Date: 16 Feb 85 20:29:40 GMT
From: guy@rlgvax.UUCP (Guy Harris)
Subject: commands within ``make''
> Is there a good reason why an option cannot be added
> to ``make'' so that it will directly execute subcommands
> such as the compiler, instead of invoking a subshell?
Stu Feldman thought it was a good idea - that's why he put it into "make"
when he wrote it. The following code comes from "dosys.c", V7/4.2BSD version;
the System III and System V versions do the same thing:
if(metas(comstring))
status = doshell(comstring,nohalt);
else status = doexec(comstring);
"doshell" does an "sh -c", and "doexec" chops the command string up itself
and does a "fork" and "exec".
> The only reason I can think of is to allow shell syntax
> such as pipes.
"metas()" returns 1 if the string contains any shell meta-characters (like
'|' for pipes), and 0 otherwise.
> Some tests indicate that a vfork() and execvp() go about twice as
> fast as a system().
Not surprising, considering you don't have to fire up "/bin/sh". However,
neither version of "make" uses "vfork" - it uses "fork" instead, probably
because the child fiddles with various things before execing.
Guy Harris
{seismo,ihnp4,allegra}!rlgvax!guy
------------------------------
Date: 29 Jan 85 03:50:17 GMT
From: dt@ist.UUCP (David Tilbrook)
Subject: Make bug
I recently found the following bug (feature?) in System 3, 5, OSx Make
in the following shell script:
cat <<'!' >make.tmp
MAIN:
echo *
!
make -f make.tmp
make -f - <make.tmp
The outputs on all my systems (4.1, SysV, OSx) in empty directories were:
echo *
make.tmp
echo *
*
Is this an obscure and useful feature the value of which I
fail to understand or appreciate?
--
David Tilbrook {inset, root44, mcvax, qtlon}!ist!dt
Imperial Software Technology, London England
------------------------------
Date: 6 Feb 85 20:02:31 GMT
From: wescott@ncrcae.UUCP (Mike Wescott)
Subject: Make 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)
{
if (fstat(dirf, &statb) != -1 &&
(statb.st_mode & S_IFMT) == S_IFDIR)
dir++;
else
close(dirf);
}
The asuumption is that open will never return 0; the check should be >= 0.
How is it that stdin is not open? In make, in main.c while parsing the
-f flag, the routine rddescf() is called. rddescf() fopen's the file named
by the argument following the -f flag unless it is "-". The file pointer
retruned by fopen or stdin is then passed to rdd1() which reads and fcloses
the file passed to it; hence when "-f -" is used stdin is closed before
/bin/sh is called. This is also a bug since
make -f - -f -
won't work properly, but then it's kinda silly anyway.
Mike Wescott
NCR Corp.
mcnc!ncsu!ncrcae!wescott
akgua!usceast!ncrcae!wescott
------------------------------
Date: 12 Feb 85 02:48:57 GMT
From: ed@mtxinu.UUCP (Ed Gould)
Subject: Make bug
I get the following on 4.2bsd, using the 4.2 make and also Doug Gwyn's
System V make (/usr/5bin/make). Note that since I generated this
with "script" the file "typescript" also appears. (Editing to change
the ../xx file is omitted.)
(ed) mtxinu> cat ../xx
cat <<'!' >make.tmp
MAIN:
echo *
!
make -f make.tmp
make -f - <make.tmp
(ed) mtxinu> /bin/sh ../xx
echo *
make.tmp typescript
echo *
make.tmp typescript
(ed) mtxinu> cat ../xx
cat <<'!' >make.tmp
MAIN:
echo *
!
/usr/5bin/make SHELL=/bin/sh -f make.tmp
/usr/5bin/make SHELL=/bin/sh -f - <make.tmp
(ed) mtxinu> /bin/sh ../xx
echo *
make.tmp typescript
echo *
make.tmp typescript
(ed) mtxinu>
I guess it's fixed here!
--
Ed Gould mt Xinu, 739 Allston Way, Berkeley, CA 94710 USA
{ucbvax,decvax}!mtxinu!ed +1 415 644 0146
------------------------------
Date: 15 Feb 85 02:43:41 GMT
From: guy@rlgvax.UUCP (Guy Harris)
Subject: Make bug
> 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:
> 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
------------------------------
Date: 18 Feb 85 22:46:28 GMT
From: nancy@resonex.UUCP (Nancy Blachman)
Subject: Makefiles are for more than just compilations?
I am interested in how people are using makefiles. I am using makefiles
for running lint, cleaning up a directory, and producing printouts.
What are you using makefiles for? (Examples are appreciated.) I'll
collect, sort, sift through and post what remains to the net.
/\//\//\//\/
Nancy Blachman UUCP: {allegra,hplabs,ihnp4,ucbvax!sun}!resonex!nancy
(408)720 8600 x37 ARPA: sun!resonex!nancy@ucbvax.ARPA
------------------------------
Date: 20 Feb 85 19:22:56 GMT
From: nz@wucs.UUCP (Neal Ziring)
Subject: Makefiles are for more than just compilations?
I use make for:
- compiling and running ada programs
- nroff-ing and troff-ing documentation
- doing backups (experiment which failed)
- cleaning out directories
- checking things in and out of rcs "archives"
- translating data tables to C header files
- compiling, running, listing, and beautifying C, lisp and
even fortran programs
Things which I have though about using make for but have
never tried include:
- adding new users
- removing users
- setting up terminal types
--
========
...nz (ECL - we're here to provide superior computing)
Washington University Engineering Computer Laboratory
[ Remember: You can't spell `eCStacy' without `CS' ]
old style: ... ihnp4!wucs!nz
new style: nz@wucs.UUCP
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / ihnp4!{wnuxa!heiby|wnuxb!netnews}
AT&T Information Systems, Inc.
Lisle, IL (CU-D21)