Unix Technical Digest V1 #54
Heiby
netnews at wnuxb.UUCP
Wed May 1 13:30:37 AEST 1985
Unix Technical Digest Wed, 1 May 85 Volume 1 : Issue 54
Today's Topics:
750 hang on boot (console config)
awk output to many files
Erroneous 4.2 bsd system makefile?
Extending the UNIX pathname syntax (2 msgs)
Need CTS/RTS handshake driver for DZ11
pdp15
RCS
----------------------------------------------------------------------
Date: Mon Apr 29 13:12:57 1985
From: dan at msdc.UUCP
Subject: 750 hang on boot (console config)
Just a couple of fine points here:
#1: Turning off ^s/^q on the LA100 makes it henceforth useless since
it will overflow its little buffer. Work-arounds are to reduce the
console speed to 1200 baud or to tweak the console driver so that it
drops the ^s in the receive buffer when it starts to listen.
#2: DEC FS was as mystified as we were about the problem. Since at
that time Ultrix didn't exist and we had the first Unix LA100 console
in Atlanta, you can't really fault them for not finding the problem on
the first glance. It really looked like it was a software problem (and
when you think about it for a moment, it was!).
Dan Forsyth ({akgua,gatech,mcnc}!msdc!dan)
Medical Systems Development Corporation, Atlanta, GA
------------------------------
Date: 23 Apr 85 21:07:43 GMT
From: henry at utzoo.UUCP (Henry Spencer)
Subject: awk output to many files
As has been noted in the past, awk(1) has an annoying limitation on the
number of files it can send output to. It's hard to get around this,
since the file opens are implicit and there is no way to explicitly
close a file that is no longer needed. However, it's possible, and
not even very hard, to eliminate this problem in one particular case.
When the file is being used for appending (">>" redirection), then
closing it and re-opening it is a no-op. The following changes to
awk will let it re-use append-mode file descriptors when it runs low
on descriptors. There's a substantial performance loss, of course,
but it occurs only when you are genuinely using more files than awk
would normally permit.
All these changes are in awk/run.c. Line numbers should be considered
approximate only. Add the following new member to the "files" struct:
13a14
> int appending;
Add the following new declaration to the local variables in the function
redirprint():
844a846
> int app;
Make the following changes to code early in redirprint():
852,856c854,867
< for (i=0; i<FILENUM; i++)
< if (files[i].fp == 0)
< break;
< if (i >= FILENUM)
< error(FATAL, "too many output files %d", i);
---
> app = -1;
> for (i=0; i<FILENUM && files[i].fp != 0; i++)
> if (files[i].appending)
> app = i;
> if (i >= FILENUM && app == -1)
> error(FATAL, "too many output files %d", i);
> if (i >= FILENUM) { /* but there is an append we can close */
> fclose(files[app].fp);
> files[app].fp = 0;
> free(files[app].fname);
> files[app].fname = 0;
> files[app].appending = 0;
> i = app;
> }
And, slightly further down in redirprint(), add the following line just
after the "files[i].fname = tostring(x.optr->sval);" line:
865a877
> files[i].appending = (a == APPEND) ? 1 : 0;
Note that this code makes no attempt to intelligently choose *which*
append-mode file descriptor to close; it probably ought to use LRU or
something like that.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
------------------------------
Date: Sat, 27 Apr 85 17:51:31 est
From: allegra!phri!roy (Roy Smith)
Subject: Erroneous 4.2 bsd system makefile?
The following is an excerpt from /sys/GENERIC/makefile on my 4.2
bsd system. I've left out some of the details of the grep/sed/awk pipe.
depend:
grep [...] | sed [...] | awk [...] > makedep
(1) echo '$$r makedep' >>eddep
(2) echo '/^# DO NOT DELETE THIS LINE/+1,$$d' >eddep
(3) echo '$$r makedep' >>eddep
(4) echo 'w' >>eddep
cp makefile makefile.bak
ed - makefile < eddep
rm eddep makedep
The lines I've numbered are clearly building an 'ed' script.
Line (1) is a no-op isn't it? It looks to me like line (1) is just an
erroneous duplicatation of line (3) which was never noticed becuase it
doesn't do any harm. Am I missing something obvious?
------------------------------
Date: 22 Apr 85 09:51:43 GMT
From: scc%cl-steve.cam at ucl-cs.arpa (Stephen Crawley)
Subject: Extending the UNIX pathname syntax
In a message on labelled tapes, Doug Gwyn writes
> This is getting silly. How are you going to specify a label to
> something like:
> myprog > /dev/rmt0
What about
myprog > /dev/rmt0/thelabel
In more general terms, it ought to be possible to pass device or socket
specific parameters in the open() pathname. When resolving a pathname, the
kernel knows that the inode corresponding to rmt0 is a special file. Why not
simply pass any characters following rmt0/ through to the device driver's open
routine for interpretation? The string after the / does not even have to
conform to the contentional pathname syntax.
There are many places where this would be useful. For tapes, there are not
only labels to specify. Tape density, rewind-on-close and other parameters
which are currently handled by stealing bits from the minor device number
would be better handled this way. It is cleaner, and would make it possible
to take out a lock on a tape drive [advisory in 4.2 Bsd, hard in Sys V]
without having to worry that a tape drive has many inodes [/dev/rmt0 /dev/mt0
etc.].
A more interesting use of a mechanism like this would be for specifying the
name of a network service and service specific open parameters to a network
access device. The current method for doing this in the absence of 4.2 Bsd
style networking is to open a network channel device, and specify the service
name and connection parameters by means of ioctls. 4.2 Bsd is better, but it
is still necessary to use different mechanisms [connect() rather than open()]
to set up a network connection, and it provides no generalised way of sending
``open parameters'' [some protocol families can't do without them ... but that
is another matter].
I've provided enough canon fodder for now ... what do people think?
Stephen C. Crawley
ARPA: scc%cl.cam.ac.uk at ucl-cs.ARPA SMail: Cambridge University Computer Lab.,
JANET: scc at uk.ac.cam.cl Corn Exchange Street,
PHONE: +44 223 352 435 Cambridge CB2 3QG, England.
USENET: ....!mcvax!ukc!camjenny!scc (might work)
------------------------------
Date: 27 Apr 85 21:11:31 GMT
From: djl at fisher.UUCP (Dan Levin N6BZA )
Subject: Extending the UNIX pathname syntax
My XENIX 3.0 machine (Intel 310/286) uses this sort of thing to access
MS-DOS floppies. You specify /dev/floppy:msdos_pathname to a group
of MS-DOS related commands. Works rather well.
Also, V8 uses this exact method to do networking. /dev/machine_name/pathname
gets you a file on another machine transparently.
--
***dan
{allegra,astrovax,princeton,twg}!fisher!djl
The misplaced (You call *that* a ski slope??) Californian
------------------------------
Date: 27 Apr 85 23:22:56 CST (Sat)
From: ihnp4!utzoo!henry
Subject: Need CTS/RTS handshake driver for DZ11
You are stuck, almost completely. The DZ11 hardware ignores the CTS
line and provides no way to control the RTS line. There is no way that
a software driver could compensate for this; it's the result of buying
cheap terminal multiplexors (DZ11s) rather than good ones.
The one bare possibility is to rewire the cable to get your signals
through on lines that the DZ11 *does* provide, and then alter the
software to interpret those lines appropriately. The DZ11 provides,
as I recall, hardware for RI, CD, and DTR only. The first two are
inputs, the last is an output. It's just conceivable that there may
be an x.yBSD driver that interprets these lines in a suitably non-
standard way, to match up with your need.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
------------------------------
Date: 27 Apr 85 23:22:44 CST (Sat)
From: ihnp4!utzoo!henry
Subject: pdp15
You've got a nasty problem there. The PDP15 and the PDP11 are very
different architectures; they don't even have the same number of bits
in their words. You could write a PDP15 simulator to run on the 11,
although simulating 18-bit words on a 16-bit machine is dirty, and
you'd probably have some headaches simulating whatever operating
system the PDP15 stuff expects. But this is going to run SLOWLY.
If you need speed, you're going to have to rewrite those programs;
I know of no way to handle the problem automatically.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
------------------------------
Date: Mon, 29 Apr 85 14:12:05 est
From: seismo!hadron!jsdy (Joseph S. D. Yao)
Subject: RCS
> This tells make how to build XXX.c. I'm not a make wizard, but there is
> probably some way you could do the above by adding a default rule which
> would tell make how to build .c files from .c,v files, but that's pretty
> obscure to me right now. ...
I believe the following will do it, at the expense of not letting
you store RCS files in an RCS subdirectory:
---
.SUFFIXES: .c,v .s,v
.c,v.c:
co $@
.s,v.s:
co $@
---
(Thanks to Suzanne O'Dell)
Nicer to do this with the Purdue 'make' that lets you use ./RCS.
BTW, for those interested, SV 'make' seems to include lots of
support for SCCS, too.
Joe Yao hadron!jsdy at seismo.{ARPA,UUCP}
------------------------------
End of Unix Technical Digest
******************************
--
Ronald W. Heiby / netnews at wnuxb.UUCP | unix-request at cbosgd.UUCP
AT&T Information Systems, Inc., Lisle, IL (CU-D21)
More information about the Mod.unix
mailing list