Checksum: 08520 Path: utzoo!utgpu!ananda From: ananda@gpu.utcs.toronto.edu (Skye Stollmeyer) Date: Mon, 22-Aug-88 21:37:06 EDT Message-ID: <1988Aug22.213706.29993@gpu.utcs.toronto.edu> Organization: University of Toronto Computing Services Newsgroups: comp.unix.xenix Subject: fsck creates disk errors References: <6808@well.UUCP> <269@hawkmoon.MN.ORG> Reply-To: ananda@gpu.utcs.UUCP (Skye Stollmeyer) Distribution: na Keywords: Foxbase, tty, filters, OOPS In article <269@hawkmoon.MN.ORG> det@hawkmoon.MN.ORG (Derek E. Terveer) writes: >In article <6808@well.UUCP>, dave@well.UUCP (Dave Hughes) writes: >> [First problem] >> Secondly - if modem-callers who do NOT have terminal emulation >> programs run it - plain tty mode - the whole session is >> punctuated by OOPS's (coming from curses, I guess), and is >> totally unsatisfactory. > >I've run into the exact same problem that you have seen when entering new >terminals into the /etc/termcap file. > >Apparently, the OOPS is an exclaimation of suprise by curses when it encounters >things in the termcap file it doesn't understand. This doesn't seem to be a >documented feature. I have *not* seen this problem in terminfo files. > >I have seen the OOPS result in two different cases: > > 1. Any kind of capatilized capabilities in the termcap entry, such as > "AL", etc. Just delete all capatilized capabilities. These are > mostly "multiple commands" anyway, such as >1 line delete, etc., > which vi doesn't seem to use anyway! (arg! (:-() > > 2. Any time there are the following type of push strings in the > capability, for example, %p1 or %p2. I simply deleted these strings > with "1,$s/%p[12]//g" in vi. The removal of these substrings from > the capabilities removed the obnoxious OOPS from the screen and > didn't seem to affect the curses capability. > >Good luck, hope this helps! > >derek I've run fsck a number of times in straight succession and it continues to find the same bad inode count in superblock, another bunch of blocks to salvage from who knows where, even though i always answer yes to all the questions. The number of blocks in the system is always slightly different though. Is fsck known to be broken in this way? I've heard it is known to happen after recompiling vpix or other device drivers into the kernel.