netnews@wnuxb.UUCP (Heiby) (05/04/85)
Unix Technical Digest Sat, 4 May 85 Volume 2 : Issue 1 Today's Topics: Administrivia "#! /bin/sh vs :" CTS/RTS handshake driver for DZ11 Default make rule for RCS Dynamic loading of software Unkillable processes ---------------------------------------------------------------------- Date: Sat, 4 May 85 05:13:09 GMT From: Ron Heiby (The Moderator) <unix-request@cbosgd.UUCP> Subject: Administrivia I'm glad to see the mod.unix submissions at what seems to be a sustainable level. Keep up the good work, everybody! You might have wondered why I decided to move on to Volume 2. There is no particularly good reason. It just seemed to me that I didn't care to have a directory that was more than 1K long. Also, this is (I think) the first digest guaranteed to have no overlap with the "net.unix*" groups, as I (honestly!) no longer read them. I'm going to be in Atlanta for about a week at the Comdex show, so the next mod.unix digest will be going out when I return on May 10. Sorry for the inconvenience. I guess I'll have to come up with some method for having a temporary stand-in moderator for future absences. If you're at the show, stop by the multi-user 3B2 display at the AT&T booth and say "Hi!" Ron. ------------------------------ Date: 28 Apr 1985 23:40:07-EDT (Sunday) From: Josh Knight <psuvax1!JOSH@YKTVMH.BITNET> Subject: "#! /bin/sh vs :" Joel Miller in <183@ski.UUCP> asks why, when using a line like #!/bin/sh to assure Bourne shell interpretation, the message "restricted ..." occasionally appears. We had this bug on some Masscomps I used to use. I looked around and there is code in the Berkeley 4.2BSD version of the Bourne shell that checks to see if the name of the file contains the letter "r". The code is commented out in the version of the distribution tape we have. It seems that versions of the Bourne shell with the code left in will produce this type of message if the name of the shell file contains the letter "r". Neat! Took me several hours to figure out what was wrong with a shell script one night (I had been foolish enough to use an "r" in the name). This hypothesis is obviously quite easy to testr. Josh Knight IBM T.J. Watson Research Center josh@yktvmh.BITNET, josh.yktvmh.ibm-sj@csnet-relay.ARPA ------------------------------ Date: Thu, 2 May 85 14:08:35 pdt From: ihnp4!nsc!turtlevax!ken (Ken Turkowski) Subject: CTS/RTS handshake driver for DZ11 >From: ihnp4!utzoo!henry >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. It's true! Someone at our site has implemented it up that way; however, rather than wiring CTS on one end to RTS on the other, you wire CTS on one end to CD on the VAX, and RTS to DTR. You use it up on 4.2bsd by setting LMDMBUF and TANDEM modes. The combination makes sense, and seems to work. Ken Turkowski @ CADLINC, Menlo Park, CA UUCP: {amd,decwrl,hplabs,nsc,seismo,spar}!turtlevax!ken ARPA: turtlevax!ken@DECWRL.ARPA ------------------------------ Date: 1 May 85 20:25:57 CDT (Wed) From: ihnp4!oliveb!jerry Subject: Default make rule for RCS > .... But now: > is there a way to get a makefile set up so that for .c's and .h's in '.' > it'll use them, but for the ones it can't find it'll use the copies from the > master directory? Make has an option that I find very useful for this situation. I have never found it documented, just saw it used and started using it myself. Just add some lines of the form: .DEFAULT: "command to create nonexistant sources" This apparently sets up the default rule to use when no other rules are satisified. As an example using SCCS (I don't have RCS): .DEFAULT get s.$@ By adding the above rule make will get copies of any source that do not exist in the current directory. Another useful one is: .DEFAULT ln ../src/$@ Which will, for any source not in the current directory, link to the copy in another directory. Useful when working on a private copy of a program. By the way, where does RCS come from (Berkeley, Bell, ?). I would like to get it but don't know who to contact regarding licensing. Jerry Aguirre @ Olivetti ATC {hplabs|fortune|idi|ihnp4|tolerant|allegra|tymix}!oliveb!jerry ------------------------------ Date: Wed, 1 May 85 09:04:50 edt From: Stephen Daniel <ihnp4!allegra!bellcore!decvax!mcnc!swd> Subject: Dynamic loading of software We have a simple dynamic loading scheme (for loading subroutines into running programs and executing them) that does not use "ld" and is therefor very fast. Its major drawback is that it does not perform any runtime linking. This means that the subroutines being loaded may not have any unresolved externals. We do allow the called subroutines to call a small number of routine supplied by the running program by passing pointers to functions to be called (such as printf) down to the called subroutines. I'd be happy to send more information (including source code) to anybody who cares to see it. Stephen Daniel, Microelectronics Center of NC 919 248 1947 decvax!mcnc!swd swd@mcnc (csnet) ------------------------------ Date: 02-May-85 17:41:11 MET (Thursday) From: seismo!mcvax!enea!sal!jf (Johan Finnved) Subject: Unkillable processes Scenario on Xenix 2.3 1) A process does output to a character device that does not swallow characters at all. Perhaps a CTRL-Q was missed from a printer. 2) Somebody notices the fact and kills the process. 3) The process finishes up as though an exit system call was made and closes all fd:s The process now typically hangs in the close routine for the device waiting for the output to drain (which it never does). As an additional feature all signals are set to SIG_IGN (even SIGKILL) during this cleanup, so you cannot kill it by giving a second signal. NB: The priority doen't matter since even SIGKILL is ignored !!!! Lesson learned: We probably shouldn't have any sleeping at all in the close routine of a character device. Rather if the output has to drain before some post-processing (such as lowering a control signal) a flag could be set meaning that the post-processing should be done when the output has drained. The flag could be checked periodically and if it stays set too long the output buffer could be flushed and the post-processing could be done anyway. ------------------------------ End of Unix Technical Digest ****************************** -- Ronald W. Heiby / netnews@wnuxb.UUCP | unix-request@cbosgd.UUCP AT&T Information Systems, Inc., Lisle, IL (CU-D21)