[net.news.b] Does anyone have a vnews for 4.2bsd?

smk@axiom.UUCP (Steven Kramer) (01/11/84)

The signal stuff doesn't work for vnews.  I put in most of the fixes
that came over the net on our vnews, but the signal stuff is off,
especially on the ^Z.  (It doesn't stop, but infinitely loops
redrawing the screen).  I'd appreciate the mods to make it to 4.2.

Also, the follow and reply shell scripts pass 2 arguments to the
editor in the version we have.  Why is that?  Does anyone have the
correct shell scripts?  (I didn't change it to what I thought because
I don't understand what was trying to be done.)

Much appreciated for any help.
-- 
	--steve kramer
	{allegra,genrad,ihnp4,utzoo,philabs,uw-beaver}!linus!axiom!smk	(UUCP)
	linus!axiom!smk@mitre-bedford					(MIL)

mark@cbosgd.UUCP (01/12/84)

Fixing news for 4.2BSD is nontrivial.  It involves using setjmp/longjmp
and setting a flag so that the longjmp will only be done when there is
something ready to catch it.

In the meantime, for those of you upgrading to 4.2BSD, here are two things
you can do.

(1) Use your 4.1BSD binary of readnews.  I know this works for a 4.1c binary,
and it should work for a 4.1 binary, but I haven't tried it.  This works
only if you have compatibility mode compiled into the kernel.

(2) Create a signal.o file from your old 4.1 libc.a or signal.s, using the
4.1 signal system call number (48).  Load with signal.o before libc gets
called.  This will invoke the 4.1 compatibilty mode signal mechanism in
the kernel, and allow you to recompile.  I haven't tried this.

	Mark

guy@rlgvax.UUCP (Guy Harris) (01/13/84)

I believe method 2) (using the old "signal" system call) will also only work
if you've compiled compatibility mode into the kernel.  (It would solve the
great "4.2BSD broke the signal mechanism!" complaint - if you need the old
semantics, and can build and use a kernel with the compatibility stuff in it
or can get at the source and build one with the old signal call, do it
that way.)

	Guy Harris
	{seismo,ihnp4,allegra}!rlgvax!guy

john@genrad.UUCP (John Nelson) (01/13/84)

Huh?  I found fixing vnews to be pretty trivial!  It didn't involve any
longjmp/setjmp stuff either!  All that was needed was to fiddle with the
interrupt mask word (sigblock/sigsetmask) in the SIGTSTP handler routine

Maybe I ignore some infrequent race condition, but we've been running it
for about two weeks now, and no one has had news die in any new mysterious
way!

If there is a serious problem, lets see a new release soon!

john@genrad.UUCP (John Nelson) (01/13/84)

A "signal" system call is provided in the standard library for 4.2BSD
(look in section 3C - compatibility library)  The differences between
this signal and the old signal are twofold:

1.  The signal trapping routine is NOT reset to the default: each handler
    must do this explicitly if it is the desired action

2.  When the signal handler routine is invoked, the signal MASK bit is
    set for that signal (see sigblock/sigsetmask).  Additional signals
    of the same type that invoked the handler routine will be blocked
    until the handler returns (or longjmps, or explicitly resets the mask)

Neither of these incompatibilities is insurmountable if you have the
source code.  In fact, in the programs I have been converting to 4.2,
the most common problem is that of a SIGTSTP handler which resets the
terminal parameters, and then kill's itself with SIGTSTP.  The routine
below fixes the problem:

tstp_catcher() {
	/* I am called to catch tstp and fix the tty mode before stopping */
	stty(1, &old_tty_parameters);
	signal(SIGTSTP, SIG_DFL);
#ifdef BSD4_2
	/* clear SIGTSTP mask bit */
	sigsetmask(sigblock(0) & ~(1 << (SIGTSTP-1)));
#endif
	kill(0, SIGTSTP);

	/* execution resumes here on a SIGCONT */
	stty(1, &new_tty_parameters);
}