Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site denelcor.UUCP Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!godot!harvard!seismo!hao!denelcor!lmc From: lmc@denelcor.UUCP (Lyle McElhaney) Newsgroups: net.unix-wizards Subject: reply on dump tapes and stopping in CBREAK. Message-ID: <611@denelcor.UUCP> Date: Thu, 6-Dec-84 00:48:22 EST Article-I.D.: denelcor.611 Posted: Thu Dec 6 00:48:22 1984 Date-Received: Sat, 8-Dec-84 05:25:22 EST Distribution: net Organization: Denelcor, Aurora, Colorado Lines: 33 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