[net.unix-wizards] reply on dump tapes and stopping in CBREAK.

lmc@denelcor.UUCP (Lyle McElhaney) (12/06/84)

A couple of notes on things I saw tonight in unix-wizards
(I'd mail it, but the addresses were black magic through
brl):

	Missing a base note, but it seems that someone has
a dump tape that went off the end. All versions of dump
on Berkeley systems (and v7 and 32v - Sys III & V call
dump obsolete and ignore the problem) ignore the eot tape
mark, and compute the number of blocks to write to fill
a (default) 2400 ft tape. If the tape is flakey and a number
of write errors occur, the blocks can wind up writing off
the end of the tape. Use the option for specifying the
tape length, and specify 2300 feet. And yes, that's not the
best way to run a railroad....

(I hope the answer matches the problem.)

	Another note asked how to put a CBREAK task back
into CBREAK after stopping and restarting. All the editors
I've seen trap SIGSTOP in a specific handler, where they
save whatever state they want to save and then kill
themselves (with a SIGSTOP). Upon return they reset the
signal, repaint their screen, do the CBREAK ioctl, and
return. This, of course, assumes the Berkeley job control;
I don't think this is possible under S5, since there are
no user level hooks. I guess there the kernel "knows"
to reset your state correctly, right? Hmmm......

Lyle McElhaney
....denelcor!lmc
-- 
		Lyle McElhaney
		(hao,brl-bmd,nbires,csu-cs,scgvaxd)!denelcor!lmc

chris@umcp-cs.uucp (12/09/84)

> ... All the editors I've seen trap SIGSTOP in a specific handler,
> where they save whatever state they want to save and then [stop].

Close, but no cigar; SIGSTOP is one of the ``holy'' signals that
Thou Shalt Not Interfere With.  ^Z generates SIGTSTP.  'Nuff.
-- 
(This line accidently left nonblank.)

In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (301) 454-7690
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@maryland