netnews@wnuxb.UUCP (Heiby) (05/01/85)
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@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@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@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@ucl-cs.ARPA SMail: Cambridge University Computer Lab., JANET: scc@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@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@seismo.{ARPA,UUCP} ------------------------------ End of Unix Technical Digest ****************************** -- Ronald W. Heiby / netnews@wnuxb.UUCP | unix-request@cbosgd.UUCP AT&T Information Systems, Inc., Lisle, IL (CU-D21)