Unix Technical Digest V2 #1

[Heiby]

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 at 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 at YKTVMH.BITNET>
Subject: "#! /bin/sh  vs :"

Joel Miller in <183 at 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 at yktvmh.BITNET,  josh.yktvmh.ibm-sj at 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 at 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 at 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 at wnuxb.UUCP | unix-request at cbosgd.UUCP
AT&T Information Systems, Inc., Lisle, IL  (CU-D21)