jgd@unix.UUCP (John G. De Armond) (10/13/89)
In article <1381@ctisbv.cti-software.nl> pim@cti-software.nl (Pim Zandbergen) writes: >jgd@rsiatl.UUCP (John G. De Armond) writes: > >>Other problems you have not mentioned. uugetty does not respect lock files. >>I've seen it get in such a nice conversation with another login that >>it locks all keyboard input, which means Big Red Switch time. > >At first I had the same problem with uugetty. > >This was because of a mistake in /etc/inittab: > >A3:234:respawn:/usr/lib/uucp/uugetty -r -t 60 /dev/ttyA3 19200 > >I changed this to: > >A3:234:respawn:/usr/lib/uucp/uugetty -r -t 60 ttyA3 19200 > >and everything works fine. Hmm... Thanks for the information. I'll give it a try. I think I'll ultimately keep using my uutty program because if for no other reason I have the source. Plus it is smarter than the supplied uugetty. Now the question. Is not the requirement to give a port as a relative address a bug? All my Unix documentation from other systems as well as this one list the paths as absolute. Plus the inittab lines in /etc/conf/default/asy (i think that's the path) list absolute paths. Is the use of relative paths permitted or is this just another bug. Speaking of bugs, check out the factor command. Thanks to ke4zv, gary for finding this one. Factor is supposed to factor a number into its primes. IT seems to think many even numbers and most multiples of 8 are prime! Try the number 662 for example. Or 8. here is the output for 662: 662 662 Here is the output for 8: 8 8 But it works for 10: 10 5 2 A question for you kernal hacks. Is factor() used in computing the encrypted password? If so, is this a security problem. --------------------------- next problem Has anybody noticed that diskverify does not work? I have a large but fairly bad scsi drive which has hundreds of known bad sectors. Diskverify pauses on each but does not log any bad sectors. And yet the drive is obviously bad, as kernal messages tell me very loudly. I could write a book on techniques I've used to identify these sectors and feed them into mkpart. ---------------------------- Yet another gotcha. I'm not sure if this could be classified as a bug but it sure is a trap in using mkpart. I recently reconfigured my system to have a small but very reliable root system and the big scsi for the rest of the system. After I had reconfigured, I restored /usr, /news and the other partitions from tape. I forgot that the old /etc/partitions was written back out from tape. One of my standard procedures after changing configuration is to make a hard copy of configuration data. I normally make a copy of the VTOCs by using the -t option of mkpart that is supposed to only print out VTOC statistics. This time, when I issued the "mkpart -tvpa disk0" command, mkpart responded with "Configuration does not match partitions - attempting to reconfigure." The system then crashed big-red-switch style and when I tried to reboot, the root drive was trashed! If this is not a bug, then it is an open trap. To me, for a status request, which one would assume to be a read-only operation, to initiate potentially destructive action with no asking for confirmation is totally unacceptable. ----------------------------- Finally, anybody know how cpio detects end-of-tape in order to ask for the next media? Or for that matter, how does diskverify trap the bad sector kernel messages in order to know when it has detected an error? I have RTFMed until my eyes have crossed. Some experienced advice here would be welcome. Thanks, John -- John De Armond, WD4OQC | Manual? ... What manual ?!? Radiation Systems, Inc. Atlanta, GA | This is Unix, My son, You gatech!stiatl!rsiatl!jgd **I am the NRA** | just GOTTA Know!!!