Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!haven!adm!xadmx!postmaster@"[unknown]" From: postmaster@[unknown] (SMTP MAILER) Newsgroups: comp.unix.wizards Subject: Mail Delivery Problem Message-ID: <18901@adm.BRL.MIL> Date: 31 Mar 89 22:15:00 GMT Sender: news@adm.BRL.MIL Lines: 1773 ----Reason for mail failure follows---- Sending mail to host drum : Unrecognized host name or address. ----Transcript of message follows---- Date: 31 Mar 89 14:45:00 WET From: unix-wizards@BRL.MIL Subject: UNIX-WIZARDS Digest V7#036 To: "baynes" Return-Path: Received: from SEM.BRL.MIL by nusc.arpa with SMTP ; Fri, 31 Mar 89 14:40:27 EST Received: from SEM.BRL.MIL by SEM.brl.MIL id aa08972; 31 Mar 89 2:56 EST Received: from sem.brl.mil by SEM.BRL.MIL id aa08937; 31 Mar 89 2:45 EST Date: Fri, 31 Mar 89 02:45:37 EST From: The Moderator (Mike Muuss) To: UNIX-WIZARDS@BRL.MIL Reply-To: UNIX-WIZARDS@BRL.MIL Subject: UNIX-WIZARDS Digest V7#036 Message-ID: <8903310245.aa08937@SEM.BRL.MIL> UNIX-WIZARDS Digest Fri, 31 Mar 1989 V7#036 Today's Topics: Re: friendly messages Re: /etc/rmt on suns -- does it work? Having trouble, TFM doesn't help Wanted: POSIX and ANSI C, details and libraries Re^2: Using sigvec & sigcontext Re: help needed on a unix system-call question Re: Wanted: POSIX and ANSI C, details and libraries Re: micro-code upgrade (and VMS vs. Unix stats) Re: namei broken Re: Implications of large memory systems ranlib: out of memory Re: Reading raw input from /dev/tty using shell RCS Can I tell if my console output is redirected (TIOCCONS)? processor problems...or just ugliness? Re: RCS Re: namei broken Problems using ACC ACP5250 under 4.3-tahoe Re: Indent posting Re: Re^2: Using sigvec & sigcontext find: bad status-- /u/tu Re: friendly messages Re: Problems using ACC ACP5250 under 4.3-tahoe Re: modems dmf-32s Re: namei broken 386s and implied OS support GALACTIC HACKER PARTY Re: Wanted: POSIX and ANSI C, details and libraries Re: RCS Re: micro-code upgrade (and VMS vs. Unix stats) Re: namei broken Re: find: bad status-- /u/tu Re: micro-code upgrade (and VMS vs. Unix stats) Re: Indent posting Re: ranlib: out of memory Re: friendly messages Booting PWB Unix1.0 to single user Re: Re^2: Using sigvec & sigcontext Re: friendly messages Locking errors uucp killing Re: micro-code upgrade (and VMS vs. Unix stats) mk doesn't work the way I expect Re: friendly messages ----------------------------------------------------------------- From: Jim Prescott Subject: Re: friendly messages Date: 29 Mar 89 06:23:02 GMT To: unix-wizards@sem.brl.mil In article <3314@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >Perhaps we (the usenet community) should spec a better interface: A nice quick 90% solution is a printf-like function that writes to stderr, prepends the program name to the message, and can append the system error message. Something like: if (open(fname, O_RDRW, 0) == -1) errmsg("Cannot open \"%s\" for read/write -- ", fname); would output: prog: Cannot open "somefile" for read/write -- Read-only file system This makes it fairly painless for the programmer to come up with an informative message without worrying about the little details. Trying to use perror to get a nice message is too much work, which is probably why it isn't used as often as it should be. The problems in implementing this are: - finding the program name; most likely needs to be stashed away while in main(). (It would have been nice if the ANSI-C folks had invented some globals to hold copies of main's arguments. (I know it isn't their job to invent :-).) - deciding where to put the system error. The code below tacks it on the end of the message iff it doesn't end in a newline. Not a great solution but certainly much simpler than doing a new % escape. An enhancement would be introduce error levels (we use FATAL, ERROR, INFO and DEBUG) and provide some way to specify which you want to see (we default to FATAL & ERROR). I've even enclosed a function to implement it below (about 99% of which is from an article on varargs by Chris Torek). I'm not sure how portable vsprintf is, its on our sun but wasn't in V7 so it probably isn't universal. If anyone can tell me where to get a pd vsprintf I'd be grateful. While we're on the subject, Guy mentioned TECO error messages but not how nifty they actually are. You can tell it to print just the 3 letter code (eg. ?FNF), to print the 1 line error (eg. ?FNF File not found.) or to print the 1 line message followed by a couple of likely paragraphs out of the manual (this is called "war and peace" mode). Its flexible even if not overly useful (I can't imagine using anything other than 1 line messages. Maybe the 3 letter only would be good on 110 baud ttys). ========= varargs version #include int errmsg(va_alist) va_dcl /* N.B.: no semicolon */ { int ret; char *fmt; va_list ap; char buf[1024]; /* shouldn't be fixed size */ va_start(ap); fmt = va_arg(ap, char *); ret = vsprintf(buf, fmt, ap); va_end(ap); fprintf(stderr, "%s: %s", Progname, buf); if (*(buf + strlen(buf) - 1) != '\n') perror(""); return ret; } #endif ========= stdarg version #include int errmsg(char *fmt, ...) /* the `...'s are part of the syntax */ { int ret; va_list ap; char buf[1024]; /* shouldn't be fixed size */ va_start(ap, fmt); ret = vsprintf(buf, fmt, ap); va_end(ap); fprintf(stderr, "%s: %s", Progname, buf); if (*(buf + strlen(buf) - 1) != '\n') perror(""); return ret; } -- Jim Prescott moscom!jgp@cs.rochester.edu {rutgers,ames,harvard}!rochester!moscom!jgp ----------------------------- From: "David C. Cornutt" Subject: Re: /etc/rmt on suns -- does it work? Having trouble, TFM doesn't help Date: 29 Mar 89 03:18:04 GMT To: unix-wizards@sem.brl.mil In article <3274@ttrdc.UUCP>, levy@ttrdc.UUCP (Daniel R. Levy) writes: > I have made the apparent mistake of believing the SUN manpage rmt(8C) for > /etc/rmt, the remote magtape daemon. According to the documentation, as I > read it, I should be able to start /etc/rmt and feed it commands and data, and > expect acknowledgments and data back from it. Well, that doesn't seem to work > very well (read: at ALL). I tried it locally (that shouldn't matter, should > it?) and here's what happens with a tape, write protect turned off (i.e. > writeable), in drive /dev/rst0, on a SUN4 under SunOS 4.0: > > O /dev/rst0 438 [me -- note that 438 decimal is 0666 octal] ^^^^^^^^^ ^^^ > Daniel R. Levy UNIX(R) mail: att!ttbcad!levy I went through this same exercise about a year ago. If I remember right (which I frequently don't), you have to put each of the arguments to every command on a line by itself; i.e., separate the command args with newlines instead of spaces. Sorry about not having a signature or return path. I just got back on the net after a long absence, and I haven't learned the local topology yet. David Cornutt uahcs1 ----------------------------- From: Lee McLoughlin Subject: Wanted: POSIX and ANSI C, details and libraries Date: 28 Mar 89 17:30:00 GMT Sender: lmjm@doc.ic.ac.uk To: unix-wizards@sem.brl.mil I'm working on large program that I want to be as portable as possible. Although it is mainly aimed at Unix boxes I thought I'd throw caution to the wind and write it using the emerging standards: POSIX and ANSI C. The first problem is how do I get ahold of the POSIX spec' in the UK? Although I've heard a lot of discussion about POSIX and seen some libraries that a POSIX compatiable (Doug Gwyn's directory scanning code for example) I don't recall seeing the name of a book, or whatever, detailing POSIX. ANSI C is easier to get ahold of details. I just bought the 2nd edition of K&R. It seems to be a good general guide, but stddef.h, errno.h and locale.h don't seem to be documented anywhere. I'd really like pointers to official publications detailing POSIX and ANSI C. If anyone knows how to get them in the UK I'd be very grateful. While I'm asking I'd like public or freely available implementation of POSIX or ANSI C libraries so that I can port to a wider range of systems. So far I've only Doug Gwyn's directory stuff and a couple of programs for converting ANSI C to K&R C (ansi2kr an agcp). Any other contributions would be greatly appreciated. thanx in advance Lee -- Lee McLoughlin 01 589 5111 X 5028 Department of Computing,Imperial College,180 Queens Gate,London SW7 2BZ, UK Janet: lmjm@uk.ac.ic.doc Uucp: lmjm@icdoc.UUCP, ukc!icdoc!lmjm DARPA: lmjm@doc.ic.ac.uk (or lmjm%uk.ac.ic.doc@nss.cs.ucl.ac.uk) ----------------------------- From: Rene' Seindal Subject: Re^2: Using sigvec & sigcontext Date: 28 Mar 89 01:30:32 GMT Sender: news@freja.diku.dk To: unix-wizards@sem.brl.mil chris@mimsy.UUCP (Chris Torek) writes: > In article <4549@freja.diku.dk> seindal@skinfaxe.diku.dk (Rene' Seindal) writes: > >On 4.3BSD on Vaxen, the struct sigcontext has the same contents as a > >``jmp_buf'' (??), > Not so: > % egrep jmp_buf /usr/include/setjmp.h > typedef int jmp_buf[10]; > % egrep sc\|\{\|\} /sys/h/signal.h > struct sigvec { > }; > struct sigstack { > }; > struct sigcontext { > int sc_onstack; /* sigstack state to restore */ > int sc_mask; /* signal mask to restore */ > int sc_sp; /* sp to restore */ > int sc_fp; /* fp to restore */ > int sc_ap; /* ap to restore */ > int sc_pc; /* pc to restore */ > int sc_ps; /* psl to restore */ > }; > As you can see, sigcontext is not an array of 10 int's. I hate to argue with you. You are right too often :-) I said same contents, not same type. A close look at setjmp will reveal that is only uses the first seven longwords of the jmp_buf, for exactly the values shown above. A comment even says "# construct sigcontext"! jmp_buf is probably only declared as an array, so people don't have to take the address themselves. (I am looking in MORE/bsd sources from Mt. Xinu, marked "@(#)setjmp.s 5.5 (Berkeley) 3/9/86"). > >Even more amusing, the is an undocumented system call (no. 139) in at least > >4.3 (and 4.2) from Berkeley, Ultrix 2.0, and SunOS 3.X (and 4.0, according to > >adb. I haven't tried), which is used by longjmp(3) to restore the saved > >context. It takes a jmp_buf/struct sigcontext as the sole argument. It is a > >kind of simplified sigreturn(2). Don't look in sysent for it, since it will > >probably not be there. > 139 is (was) the `sigcleanup' syscall, used in 4.2BSD to exit from > signal handlers, and indeed undocumented. It did not take *any* > arguments; rather, it found a sigcontext structure via the user stack > pointer pushed by the `chmk' trap, an awful and bloody thing to do, > which is of course why it was fixed in 4.3BSD.... You are right about the argument passing. It does, however, look the same from user code. Code like pushl chmk $139 will do a longjmp (without restoring register contents, as 4.[23] longjmp does). Syscall 139 still exists in the 4.3 I use (MORE/bsd), even though it isn't listed in sysent. Look in the top of syscall(). That is an awful and bloody thing to do too. Was it left in only because of longjmp(), which is able to use sigreturn() instead (more awful and bloody code), or because other programs depended on it (even more awful and bloody)? > I have no idea how SunOS actually handles osigcleanup(). I haven't got sources to SunOS 4.0, but it look like it uses the 4.2 scheme. It has sigcleanup listed as syscall 139 in sysent, taking no arguments. The code for sigcleanup looks similar, fetching a sigcontext pointer from the user stack, followed by a copyin of the necessary parts of the sigcontext, and assignment to the saved registers in the user structure. SunOS hasn't got sigreturn either, so those parts of the kernel might be from 4.2. Rene' Seindal (seindal@diku.dk). ----------------------------- From: der Mouse Subject: Re: help needed on a unix system-call question Date: 29 Mar 89 11:57:12 GMT Keywords: signal, system-call, read, unix v Posted: Wed Mar 29 06:57:12 1989 To: unix-wizards@sem.brl.mil In article <7553@june.cs.washington.edu>, ka@june.cs.washington.edu (Kenneth Almquist) writes: > guy@auspex.UUCP (Guy Harris) writes: >> Assuming by "is it possible to lose the partially read data" you >> mean "if the 'read' blocks, and then transfers some data and blocks >> waiting for more data, and *then* gets interrupted by a signal, is >> the data it transferred more-or-less lost", the answer is "yes, and >> [...]" [...]. > Reads on cooked tty devices block until an entire line is available > and then copy in the entire line at once. The original posting seems to have expired here. There is one common case which *looks* like "partially read" data being "lost", even though this is not really true: when the signal coming in is due to a special character (interrupt or quit, for example) being typed on the tty that's being read from. In this case, the input buffer is generally flushed, losing any partial line that's been typed. Until you realize that the partial line is being buffered in the kernel and not transferred to the user's buffer until you push return (and therefore isn't partially read at all), this looks a lot like "losing partially read data". The original question probably belonged in comp.unix.questions, but we all know nobody pays any attention to the distinction any longer :-(. der Mouse old: mcgill-vision!mouse new: mouse@larry.mcrcim.mcgill.edu ----------------------------- From: Joseph Boykin Subject: Re: Wanted: POSIX and ANSI C, details and libraries Date: 29 Mar 89 14:54:18 GMT Sender: news@encore.com Followup-To: comp.std.c To: unix-wizards@sem.brl.mil In article <746@gould.doc.ic.ac.uk> lmjm@doc.ic.ac.uk (Lee McLoughlin) writes: >The first problem is how do I get ahold of the POSIX spec' in the UK? Firstly, POSIX is actually the name for what will become a set of standards. The only one currently approved is 1003.1, the system interface definition (i.e. system calls). P1003.2 recently went through its first ballot. I haven't heard what the results were, but generally it takes about 6-9 months before all the balloting objections are taken care of and a final ballot is taken. So, while "POSIX" may not be more than one standard today, there will be more than one by the end of the year. There are numerous others in development as well. Information on obtaining a coy of the 1003.1 standard is below. If you are interested in becoming active in the POSIX effort, which can mean anything from just obtaining a copy of the draft documents to actively participating in meetings, you should contact: Jim Isaak Chair, Technical Committee on Operating Systems Subcommittee on Operating System Standards (TCOS-SS for short!) DEC, MS ZK03-3/Y25 110 Spit Brook Road Nashua, NH 03062 603-881-0480 You can obtain a copy of the 1003.1 document from either the IEEE Service Center, or from IEEE-CS Publications. The catalog for the IEEE was the top-most on my desk, so here's the information: Standard Number: 1003.1-1988 Code: SH12211 Cost: $32.00 ($16 for IEEE Members) Provide Name, Address and IEEE Membership number and send your check or credit card number to: IEEE Service Center 445 Hoes Lane PO Box 1331 Piscataway, NJ 08855 in Canada: IEEE Canada 7061 Yonge Street Thornhill, Ontario L3T 2A6 Hope this helps. ---- Joe Boykin Encore Computer Corp Vice-Chair, IEEE Computer Societies' Technical Activities Board UUCP: encore!boykin ARPA: boykin@encore.com ----------------------------- From: Roy Smith Subject: Re: micro-code upgrade (and VMS vs. Unix stats) Date: 29 Mar 89 17:56:02 GMT To: unix-wizards@sem.brl.mil dodgson@cs.wmich.edu (Harry Dodgson) writes: > The DEC rep will be in this Tuesday to upgrade the microcode to > level 103. He doesn't know anything about Unix. Some number of years ago, when our 750 was fairly new, DEC came out with a "rev 7" upgrade, which was some minor change in the memory controller having to do with catching cache parity errors, or something like that (I don't remember exactly, but the details are not that important). DEC insisted on installing it on our 750 and I foolishly let them. The result was weeks (or was it months?) of agony. It never worked right and DEC insisted on putting the blame on the fact that we were running Unix. Eventually, after GOK how many board swaps, they got us a board that worked, claiming that they were special-testing boards to find ones that ran under Unix. When I say I "foolishly" let them install it, what I mean is that until they did the upgrade, we didn't have any problems; we never had the symptoms that the upgrade was supposed to cure and after the upgrade we had *lots* of problems. My advice is to ask DEC just *why* they want to install the new microcode, and don't let them unless they have a damn good reason. If your machine works as it is, what do you have to gain by changing something? heins@atanasoff.cs.iastate.edu (Leeland Heins) writes: > ** opinion on :-) ** Does any DEC rep ever say anything but "buy VMS"? :-) I saw an interesting statistic in (of all places) MacWEEK (21 March 1989, page 60). They did a (somewhat silly) survey of Macs connected to bigger machines at 269 "very large Macintosh sites". They found that of Vaxen with "connected" Macs, 54% run only Ultrix (which I take to mean Unix of various flavors), 37% run a mix of Ultrix and VMS, and only 1% run strictly VMS. They didn't mention if these were academic or commercial sites. I hope this doesn't start another VMS vs. Unix war. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@phri.nyu.edu "The connector is the network" ----------------------------- From: Barry Shein Subject: Re: namei broken Date: 29 Mar 89 19:04:59 GMT To: unix-wizards@sem.brl.mil > namei() doesn't work! > > It's BROKEN!! What I'm trying to understand is, if it's true, how the guy posted the message or how any of us are reading or replying to it. -- -Barry Shein, Software Tool & Die There's nothing more terrifying to hardware vendors than satisfied customers. ----------------------------- From: Unix Consultation Mailbox Subject: Re: Implications of large memory systems Date: 29 Mar 89 17:57:34 GMT To: unix-wizards@sem.brl.mil In article <13433@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: > If the machine is a >workstation rather than being used for timesharing (many schools try to >put 32 users on an 8MB Sun), the total memory in use is probably 4-12MB. We have a pilot system running on a number of single-user diskless Sun 3/50s and I'll tell you exactly how much memory is in use on each of those workstations: the entire 4Mb. We had to double the size of all the server swap partitions just to keep the systems running. And even after taking the -g's and -gx's out of all the makefiles, *and* stripping all the executables, it's still Page City. >Do most users need that in a workstation? I don't, as long as I have >access to a large machine for those rare problems which can use that >much memory. I never needed more than the 4Mb in a 3/50 myself. Of course I was still doing most of my work on the Pyramids, which helps a lot. (They've all got >= 16M main memory and hundreds of Mb swap. Zippy!) phil ----------------------------- From: David Brown Subject: ranlib: out of memory Date: 29 Mar 89 18:45:15 GMT To: unix-wizards@sem.brl.mil Hiya. It seems that my ranlib is broken. I'm using a Sun 3/60 running SunOS4.0. I've got a directory of .o files that I want in an archive...so I: ar crv libjunk.a file1.o file2.o file3.o ... fileN.o a - file1.o a - file2.o a - file3.o ... a - fileN.o ranlib libjunk.a ranlib: ran out of memory All together, these files don't add up to 200K. Is ranlib on SunOS4.0 broken? I looked over the 'fixes' on the 4.0.1 tape, but there's nothing on ranlib. And yes, I've tried my WONDERFUL Sun software support ... I've been waiting for a return call for 6 days now. I don't have source to pick through, unfortunately. Anyone out there in netland know of a way around this? Any and all help greatly appreciated! David Brown david@pyr.gatech.edu (912) 927-5342 ps: If anyone at Sun is the least bit interested, the service order number is 284573. ----------------------------- From: Jimmy Aitken Subject: Re: Reading raw input from /dev/tty using shell Date: 29 Mar 89 19:17:17 GMT Sender: daemon@pyramid.pyramid.com To: unix-wizards@sem.brl.mil In article <52@crdgw1.crd.ge.com> barnett@crdgw1.crd.ge.com (Bruce Barnett) writes: >Does anyone know a clever method of reading raw data from /dev/tty >using a shell script and standard Unix tools? This is the method that I shell script that I use to chnage attributes of a sun window. The main program has lots of options and needs to know the current position of the window read via escape sequences. Note that you musn't type anything whilst it's trying to read the input as it would get messed up with the stuff that the sun window is "typing". This runs fine under sunOS 3.5 The code fragment goes something like: stty raw > /dev/tty echo -n "escape sequencs that causes the string to be returned" > /dev/tty ch=`dd /dev/null` stty cooked > /dev/tty This can be used e.g: echo -n "${esc}[18t" to get the size of the window >Call me a purist, but I was wondering if I could replace a 10 line C program >with a 5 line shell script? :-) Or even 4 line... ----------------------------- From: Mike McNally Subject: RCS Date: 29 Mar 89 21:01:36 GMT To: unix-wizards@sem.brl.mil When a file is checked out (with co) of an RCS directory, it seems to me that it would be nice if the modification date were set to the date of the revision. This would keep "make" happy. Because I've just started using RCS in an attempt to bring some sanity to our software, I might easily be confused. Perhaps there's a good reason that the file time should be the time of check-out, and I'm just not really in the RCS groove. Any explanations are welcome. -- Mike McNally Lynx Real-Time Systems uucp: {voder,athsys}!lynx!m5 phone: 408 370 2233 Where equal mind and contest equal, go. ----------------------------- From: Dave Cohrs Subject: Can I tell if my console output is redirected (TIOCCONS)? Date: 29 Mar 89 23:22:16 GMT Sender: news@spool.cs.wisc.edu Keywords: TIOCCONS, SunOS To: unix-wizards@sem.brl.mil I'm running SunOS 4.0.1, and I'd like to find out if my console output is redirected to a pty, and if so, take some action. How do I tell if the console output is redirected? thanks -- Dave Cohrs +1 608 262-6617 UW-Madison Computer Sciences Department dave@cs.wisc.edu ...!{harvard,rutgers,ucbvax}!uwvax!dave ----------------------------- From: Dick Dunn Subject: processor problems...or just ugliness? Date: 27 Mar 89 20:00:48 GMT To: unix-wizards@sem.brl.mil jfh@rpp386.Dallas.TX.US (John F. Haugh II) wrote a flame about the 286. First item of note is that he directed followups to "junk". I don't get it; was he afraid that someone might try to post a substantive response? > The 80286 does have problems. Meaning what? That it's uglier than last week's roadkill? Perhaps so, but: >...I doubt that a fully functional and > robust operating system for an 80286 can ever be had... There are existence proofs to the contrary. Even the Microport system, which has some long-standing bugs, *could* be fixed...people are frustrated with the bugs in the Microport AT stuff precisely because they know they can be fixed. There is nothing that I know of in the 286 architecture which prevents one from constructing, say, a correct implementation of UNIX in which processes are completely protected from one another as they should be, and in which the kernel is protected from processes such that no process could cause a kernel panic. If anyone has any concrete, substantive reason that a 286 cannot support a correct, robust operating system, I'd like to know what it is. What I'm looking for is, for example, a way that a program in user mode can cause an exception that the kernel can't defend against. Let's even include the usual support chips for the 286 since (a) it doesn't have any useful interrupt control on-chip, and (b) the 286, as ugly as it is, is actually rather pleasant next to the cascaded pair of 8259's normally used with it. I'm not much swayed by an argument like: >...The chip is brain dead and a waste of good silicon... since it's a content-free statement, and: >...Various modes of failure > cause the program to be completely aborted, and if that program > happens to be your operating system, tough luck. amounts to nothing since the same is true of "various modes of failure" on most processors. Try things like a bad kernel stack pointer, nonexistent address for load/store, etc., and see what it does to a 680x0, a VAX, a PDP-11... > ...Others of us are disgusted with bogus hardware. > The 80286 is such an example of a total loser implemented on silicon. No, it's not a total loser. That's nonsense. It IS an unpleasant processor in many ways. I won't defend the architecture, but just because it's ugly doesn't mean it's not usable. In fact, if you get in to the real details of most processors, you'll find that there are lots of warts. A very few processors are exceptionally clean in design, like the PDP-11...but even there if you go looking at the Unibus map or the memory protection, you'll find things are more ornate than you might like. Of course, the PDP-11 is probably two orders of magnitude (?quantitative subjectivity?:-) cleaner than the 286, BUT the 286 is still usable. It works (or at least if it doesn't, nobody has posted a reason yet). The 286 has a rather baroque memory protection scheme, but at least it has one. Contrast with the 680x0, which didn't have either an internal MMU or any accepted external MMU for years. That made it impossible to produce a UNIX port "for the processor" since the port depended on box-specific memory management. If you have a chance to influence architecture, it's great to complain about all the things that make an operating system ugly or slow...but if the hardware already exists, you need to take a different tack: See if everything you need to do is *possible* (note: NOT easy or clean, just possible)...then get down to it. Let me try to keep my views in perspective: I've done OS-level work on the 286, and believe me, I complained about the architecture all along. It was often painful to do things, but it was possible and the result was usable. -- Dick Dunn UUCP: {ncar,nbires}!ico!rcd (303)449-2870 ...Never offend with style when you can offend with substance. ----------------------------- From: Chris Torek Subject: Re: RCS Date: 30 Mar 89 00:07:55 GMT To: unix-wizards@sem.brl.mil In article <5372@lynx.UUCP> m5@lynx.uucp (Mike McNally) writes: >When a file is checked out (with co) of an RCS directory, it seems to me >that it would be nice if the modification date were set to the date of >the revision. This would keep "make" happy. Since `co' expands RCS keywords, this would be wrong. For instance: % co -l foo.c 1.1 locked % edit foo.c ... % make ... % ./test foo works % ci foo.c ... % co foo.c % make `foo' is up to date. % ident foo $Header: ... chris Locked $ % Other than the single `extra' recompilation (not always unnecessary, as above), if you keep a copy co'd all the time, this is no problem. Alternatively, you can use a variant of `make' that knows about RCS files. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris ----------------------------- From: Rahul Dhesi Subject: Re: RCS Date: 29 Mar 89 23:26:00 GMT To: unix-wizards@sem.brl.mil In article <5372@lynx.UUCP> m5@lynx.UUCP (Mike McNally) writes: [about timestaps of files checked out with RCS]: >Perhaps there's a good reason >that the file time should be the time of check-out... ...As opposed to the revision time. Yes, there is. Suppose you check out all files and compile. Now you change your mind and check out an earlier revision of one of the source files and type "make" again. -- Rahul Dhesi UUCP: !{iuvax,pur-ee}!bsu-cs!dhesi ARPA: dhesi@bsu-cs.bsu.edu ----------------------------- From: Roy Smith Subject: Re: namei broken Date: 30 Mar 89 02:16:40 GMT To: unix-wizards@sem.brl.mil In article <29045@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: > What I'm trying to understand is, if it's true, how the guy posted the > [namei() doesn't work!, It's BROKEN!!] message or how any of us are > reading or replying to it. Oh come on Barry, there you go showing your narrow-minded view of the universe again :-). There *are* systems capable of posting news articles that don't have namei() in them. Maybe he used a VMS system? -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@phri.nyu.edu "The connector is the network" ----------------------------- From: Patrick Barron Subject: Problems using ACC ACP5250 under 4.3-tahoe Date: 29 Mar 89 23:16:31 GMT To: unix-wizards@sem.brl.mil Has anyone successfully gotten ACC's ACP5250 driver working under 4.3-tahoe? I'm having a problem in which the kernel panics when turning the ACP5250 board on (using acpconfig); the proximate cause of the crashes is that, when the driver is trying to write to Unibus map registers (or what passes for such on a Q-bus...), the pointer it's using contains garbage, and it goes off and tries to poke at non-existent memory. This very same driver works just fine under Wisconsin 4.3BSD+NFS - did something change in the way I/O mapping is handled in the kernel? ACC *is* working on the problem, but I was just curious to know if anyone had seen it before. The sooner I can get this fixed, the better.... --Pat. ----------------------------- From: Ozan Yigit Subject: Re: Indent posting Date: 29 Mar 89 22:33:03 GMT Keywords: indent To: unix-wizards@sem.brl.mil In article <18835@adm.BRL.MIL> gaspar@st-louis-emh2.army.mil (Al Gaspar) writes: > >... has done a great job in getting the Berkeley/Sun version >of indent into the public domain. I did not do much, except to ask/bug some people, contact its original author, and those others who worked on it, to clarify its original status, copyright issues etc. >I noticed that the -bg, -dj, -ndf, -pb, and -npb options from the older >public domain version are missing from Oz's version of indent posted >to unix-sources. What I would like to know is if there is someone >else still working on indent that plans on incorporating the older >public domain version into Oz's Berkeley/Sun version? I do not know if you can call the original version public-domain, but certainly assumed to be publicly-distributable: there is some work afoot to find ways to babysit the code, and include patches, further enhancements etc. in a coordinated manner. Some folks at BSD are planning to do major revisions, and I am sure just about every option to typeset C code will be included in due time. (tomorrow ? :-) oz -- ... and I say to them, Usenet: oz@nexus.yorku.ca `Where the hell were you ......!uunet!utai!yunexus!oz when the page was blank?' Bitnet: oz@[yulibra|yuyetti] Harlan Ellison Phonet: +1 416 736-5257x3976 ----------------------------- From: Chris Torek Subject: Re: Re^2: Using sigvec & sigcontext Date: 30 Mar 89 04:04:29 GMT To: unix-wizards@sem.brl.mil >>In article <4549@freja.diku.dk> seindal@skinfaxe.diku.dk (Rene' Seindal) wrote: >>>On 4.3BSD on Vaxen, the struct sigcontext has the same contents as a >>>``jmp_buf'' (??), >to which I said >>Not so: In article <4557@freja.diku.dk> seindal@skinfaxe.diku.dk (Rene' Seindal) replies: >I said same contents, not same type. Ah: I misinterpreted. >[setjmp] uses [only] the first seven longwords of the jmp_buf.... Indeed it does. >jmp_buf is probably only declared as an array, so people don't have >to take the address themselves. Historically, jmp_buf has always been an array; and according to the pANS for C, it must be so. In fact the array was once used to hold r6 through r15 (in the days of 4.1BSD), and its size is a holdover. But the two are not interchangeable, aside from an accident of implementation (well, of design, in this case). It is reasonable for setjmp and longjmp to want to preserve more state than a sigcontext (register contents, for instance, on 680x0s, where the call frame does not let you restore registers by unwinding). Sticking with jmp_bufs for longjmp and sigcontexts for signals is much safer. >Syscall 139 still exists in the 4.3 I use (MORE/bsd) ... (and in 4.3tahoe) >Was it left in only because of longjmp() ... or because other >programs depended on it ... ? It was left in for backwards compatibility. 4.3BSD-tahoe will still run most 4.1BSD binaries. (Exceptions are things using the jobs library, and things using vread and/or vwrite. There may be others.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris ----------------------------- From: Bob Ames Subject: find: bad status-- /u/tu Date: 29 Mar 89 06:56:13 GMT Followups-To: unix-pc.general To: unix-wizards@sem.brl.mil Anybody seen this:? 3.51# find /u -print [...] /u/tutor /u/tutor/Filecabinet [...] /u/tutor/Filecabinet/Profiles/9600bps:A2 find: bad status-- /u/tutor/Filecabinet/practice/sample6.clf find: bad status-- /u/tutor/Filecabinet/practice/sample5.clf [...] find: bad status-- /u/tutor/Filecabinet/practice/sample1.clf /u/tutor/Wastebasket /u/tutor/Clipboard /u/tutor/.history find: bad status-- /u/hello find: bad status-- /u/dummy find: bad status-- /u/someone [...] 3.51# The bad status messages continue for the rest of the /u directory. The only command which seems to be bothered at all with the /u directory is find. I can cd, ls, od ., anything. All the files are there and intact. The only reason this error was discovered is that the Tape Backup software gave the same errors during the "Checking the file systems" phase of the "Complete Backup". I did an od -cx /u and the output looked somewhat reasonable for a directory. There's plenty of space left on the disk. I tried rebooting. It seems like permissions, but I'm root. This all started after we brought the machine back from ATT for a new power supply |-) Bob Bob Ames The National Organization for the Reform of Marijuana Laws, NORML "Pot is the world's best source of complete protein, alcohol fuel, and paper, is the best fire de-erosion seed, and is america's largest cash crop," USDA bob@rush.cts.com or ncr-sd!rush!bob@nosc.mil or rutgers!ucsd!ncr-sd!rush!bob 619-743-2546 "We each pay a fabulous price for our visions of paradise," Rush ----------------------------- From: Chris Torek Subject: Re: friendly messages Date: 30 Mar 89 04:16:50 GMT To: unix-wizards@sem.brl.mil In article <1411@moscom.UUCP> jgp@moscom.UUCP (Jim Prescott) writes: [much deleted; these are retained in order] > ret = vsprintf(buf, fmt, ap); > fprintf(stderr, "%s: %s", Progname, buf); > perror(""); Beware, beware! His flashing eyes, his floating exception! Oops, a bit of stream of unconsciousness there. This can produce the infamous sendmail-style message: Cannot exec /bin/mail: Not a typewriter because fprintf() can call isatty() which can set errno to ENOTTY. To fix this you should either save and restore errno, or change the code to fish the error message directly out of sys_errmsg[], or use strerror() (if your C library has it). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris ----------------------------- From: Chris Torek Subject: Re: Problems using ACC ACP5250 under 4.3-tahoe Date: 30 Mar 89 04:26:27 GMT To: unix-wizards@sem.brl.mil In article <3104@ci.sei.cmu.edu> pdb@sei.cmu.edu (Patrick Barron) writes: >Has anyone successfully gotten ACC's ACP5250 driver working under >4.3-tahoe? ... the kernel panics when turning the ACP5250 board on ... >... when the driver is trying to write to Unibus map registers ... the pointer >it's using contains garbage, and it goes off and tries to poke at >non-existent memory. Easy: Between 4.3BSD and 4.3-tahoe, Mike fixed the Unibus code so that it understands having map registers at a different location from Unibus adapter registers (if any), and to catch bugs, set the `adapter' register address to 0xc0000000. That one got caught. The map registers are now at uhp->uh_mr, rather than &uhp->uh_uba->uba_map[0]. This does not affect well-behaved vaxif drivers, as they all go through vaxif/if_uba.c. (The ACC drivers are not well-behaved.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris ----------------------------- From: "David E. Miran" Subject: Re: modems dmf-32s Date: 29 Mar 89 21:12:31 GMT To: unix-wizards@sem.brl.mil In <400@lclark.UUCP> dan@lclark writes > > What I'm trying to do is to connect some 1200/2400 baud modems to our > VAX 750 (4.3bsd unix) to use as dial-in ports. (The modems are > 'Hayes compatible' Practical Peripherals...) followed by a description of the problems involved in trying to handle multispeed modems, especially with PC terminal emulators that cannot send a break. There is a very satisfactory solution to this possible (if you are willing to buy better modems). Get some Multitech MT224EH modems (or better yet MT696EH). These are multispeed modems which run at 2400 baud (9600 for the MT696EH). These modems have the very useful feature that their phone line speed does NOT have to match the speed to the computer. They can answer the phone at speeds of 300, 1200, 2400, 4800 ( with MNP 5 compression) (also 9600 and 19,200 for the MT696EH) while always talking to the computer at a fixed speed (like 9600). The modem then uses xon/xoff to do flow control. We have some of the MT224EH modems and really like them. We are planning to get some MT696EH modems in the near furture. We can buy them for $323 for the MT224EH and $395 for the MT696EH. Of course, this is a state contract price but you should be able to get close to these prices. These modems are the ideal solution to the speed recognition problem for us. Hope this helps. -- David E. Miran ...!{rutgers,ucbvax,harvard}!uwvax!uwslh!dem Wisconsin State Hygiene Lab or dem%uwslh.uucp@cs.wisc.edu University of Wisconsin (608) 262-0019 465 Henry Mall Madison, WI 53706 ----------------------------- From: Barry Shein Subject: Re: namei broken Date: 30 Mar 89 13:32:29 GMT To: unix-wizards@sem.brl.mil > Oh come on Barry, there you go showing your narrow-minded view of >the universe again :-). There *are* systems capable of posting news >articles that don't have namei() in them. Maybe he used a VMS system? >-- >Roy Smith, System Administrator Tell ya what, we'll shut off all the Unix systems on the USENET and he can try posting it again... >"The connector is the network" Indeed. -- -Barry Shein, Software Tool & Die There's nothing more terrifying to hardware vendors than satisfied customers. ----------------------------- From: David Collier-Brown Subject: 386s and implied OS support Date: 30 Mar 89 03:01:54 GMT To: unix-wizards@sem.brl.mil From article <18250@gatech.edu>, by ken@gatech.edu (Ken Seefried iii): > I thought about that, but it is my understanding (which surely could > be wrong) that multics is based on dynamicly allocated, variable size > segments of potentially large size. Certainly, the 80286 doesn't fit > this criteria with its fixed size, 64K segments. Also, doesn't > Multics use more than 4 rings of protection? [...] > The 80386 *IS*, however, Multics-on-a-chip... > > ...ken seefried iii > ken@gatech.edu Well, its a "superset of Unix on a chip", but it falls a bit short of a good target machine for Multics. One of the big wins with Mutlicks was the integration of the file system managment with the active segment managment, which allows one to fold about three very large special cases into one (possibly overcomplex) function. This implies: a "known segment" table of large and variable size a large number of segments (ie, not four) a simple mapping from segments to pages (to cut down redundant descriptor information) This is, in my humble opinion, HARD on a 386. Not impossible, but not a shoe-in by any means. To paraphrase Henry, they shold have spent more time building implementation capabilities into the hardware, instead of building policy in... --dave (its easier to put multics on something like the GE machine with 1 accumulator and four address registers [intel segments!] than on a 386) c-b -- David Collier-Brown. | yunexus!lethe!dave Interleaf Canada Inc. | 1550 Enterprise Rd. | He's so smart he's dumb. Mississauga, Ontario | --Joyce C-B ----------------------------- From: ROP GONGGRIJP Subject: GALACTIC HACKER PARTY Date: 29 Mar 89 05:19:45 GMT To: unix-wizards@sem.brl.mil GALACTIC HACKER PARTY 2nd, 3rd, 4th of August 1989 PARADISO, AMSTERDAM, HOLLAND During the summer of 1989 the world as we know it will go into overload. An interstellar particle stream of hackers, phone phreaks, radioactivists and assorted technological subversives will be fusing their energies into a media melt-down as the global village plugs into Amsterdam for three electrifying days of information interchange and electronic capers. Aided by the advanced communications technology to which they are accustomed, the hacker forces will discuss strategies, play games, and generally have a good time. Free access to permanently open on-line facilities will enable them to keep in touch with home base -- wherever that is. Those who rightly fear the threat of information tyranny and want to learn what they can do about it are urgently invited to interface in Amsterdam in August. There will be much to learn from people who know. Celebrity guests with something to say will be present in body or electronic spirit. The Force must be nurtured. If you are refused transport because your laptop looks like a bomb, cut off behind enemy lines, or unable to attend for any other reason, then join us on the networks. Other hacker groups are requested to organize similar gatherings to coincide with ours. We can provide low-cost international communications links during the conference. For further information, take up contact as soon as possible with: HACK-TIC PARADISO P.O. box 22953 Weteringschans 6-8 1100 DL Amsterdam 1017 SG Amsterdam The Netherlands The Netherlands tel: +31 20 6001480 tel: +31 20 264521 / +31 20 237348 fax: +31 20 763706 fax: +31 20 222721 uucp : ..!mcvax!neabbs!rop fido : 2:280/1 Hack Tic telex: 12969 neabs nl Please relay this announcement through all channels of communication that you can access. SPREAD THE BYTE, SPREAD THE BYTE, SPREAD THE BYTE, SPREAD THE BYTE -----------------Amsterdam, spring 1989--------------------------- ----------------------------- From: Nick Maclaren Subject: Re: Wanted: POSIX and ANSI C, details and libraries Date: 29 Mar 89 19:31:40 GMT Sender: news@cl.cam.ac.uk Posted: Wed Mar 29 20:31:40 1989 To: unix-wizards@sem.brl.mil The people to contact about both POSIX and ANSI C in this country are the BSI. There is likely to be another ISO Draft Proposal on ANSI C, with a corresponding BSI DP, and that is a good opportunity to get a copy of the current draft. POSIX I am less in touch with. I am not sure of the best address to contact in the BSI, and it is a somewhat rambling organisation (several locations in London, Milton Keynes etc.) Try chasing up via one of the London locations. WARNING: do NOT rely on the second edition of K&R. They 'jumped the gun' and predicted the future wrong; I believe that they are working on a corrected second edition. I would also suggest working from the real standard, unless K&R second edition is considerably more thorough than the first edition. Nick Maclaren University of Cambridge Computer Laboratory nmm@uk.ac.cam.cl ----------------------------- From: Mike McNally Subject: Re: RCS Date: 30 Mar 89 15:37:06 GMT To: unix-wizards@sem.brl.mil In article <16623@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >Since `co' expands RCS keywords, this would be wrong. For instance: ... In article <6389@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >Yes, there is. Suppose you check out all files and compile. Now you >change your mind and check out an earlier revision of one of the source >files and type "make" again. OK, I see. I admit that the obvious (and nearly transparent) solution of keeping all the sources checked out (read only) is correct. In addition to these two responses, a more clued-in person here tipped me off to the scene. On the subject of RCS: I saw, in a message from some archive somewhere, mention of some sort of registration that should be carried out with the creator of the RCS system. I can't find any mention of this in the sources I have (which I think came from the usenet archive). -- Mike McNally Lynx Real-Time Systems uucp: {voder,athsys}!lynx!m5 phone: 408 370 2233 Where equal mind and contest equal, go. ----------------------------- From: Karl Kleinpaste Subject: Re: RCS Date: 30 Mar 89 18:27:43 GMT Sender: news@tut.cis.ohio-state.edu To: unix-wizards@sem.brl.mil m5@lynx.uucp (Mike McNally) writes: On the subject of RCS: I saw, in a message from some archive somewhere, mention of some sort of registration that should be carried out with the creator of the RCS system. I can't find any mention of this in the sources I have (which I think came from the usenet archive). See the file rcs/src/READ_ME in your RCS distribution tree. ----------------------------- From: Rick Ace Subject: Re: micro-code upgrade (and VMS vs. Unix stats) Date: 30 Mar 89 17:02:08 GMT To: unix-wizards@sem.brl.mil In article <3729@phri.UUCP>, roy@phri.UUCP (Roy Smith) writes: > Some number of years ago, when our 750 was fairly new, DEC came out > with a "rev 7" upgrade, which was some minor change in the memory controller > having to do with catching cache parity errors, or something like that (I > don't remember exactly, but the details are not that important). DEC > insisted on installing it on our 750 and I foolishly let them. > > The result was weeks (or was it months?) of agony. It never worked > right and DEC insisted on putting the blame on the fact that we were running > Unix. Eventually, after GOK how many board swaps, they got us a board that > worked, claiming that they were special-testing boards to find ones that ran > under Unix. When I say I "foolishly" let them install it, what I mean is > that until they did the upgrade, we didn't have any problems; we never had > the symptoms that the upgrade was supposed to cure and after the upgrade we > had *lots* of problems. > > My advice is to ask DEC just *why* they want to install the new > microcode, and don't let them unless they have a damn good reason. If your > machine works as it is, what do you have to gain by changing something? I suspect DEC will answer like this: "Because Field Service will soon refuse to support Vax-11/750 systems that are not up to Rev 7." This is true of hardware and software alike. It makes no economic sense for a vendor to support previous versions of products when the current versions are supersets of their predecessors. Now in Roy's case, the Rev 7 upgrade did not deliver a superset of what it replaced. However, it's probably true that DEC had no idea that things were going to get worse when they did the upgrade. (As an example, Field Service upgraded two 750s at NYIT to Rev 7 a few years ago, and outside of my having to figure out how to make 4.2bsd load the microcode, both upgrades went smoothly.) Roy, the best thing you could have done was to demand that DEC commit to a date (as early as you bargain for) by which they will either make Rev 7 work or return you to your previous revision level. If the local F-S manager won't buy into that, talk to his/her superior(s) until you get satisfaction. Rick Ace Pixar 3240 Kerner Blvd, San Rafael CA 94901 ...!{sun,ucbvax}!pixar!rta ----------------------------- From: "Brian V. Smith" Subject: Re: namei broken Date: 30 Mar 89 19:07:40 GMT Sender: usenet@helios.ee.lbl.gov To: unix-wizards@sem.brl.mil I hate to sound stupid when I'm just ignorant, but what is namei()? Neither our Ultrix nor SunOs systems have a manual entry for it. _____________________________________ Brian V. Smith (bvsmith@lbl.gov) Lawrence Berkeley Laboratory We don't need no stinking signatures! ----------------------------- From: Mike Wescott Subject: Re: find: bad status-- /u/tu Date: 30 Mar 89 16:30:34 GMT To: unix-wizards@sem.brl.mil In article <948@rush.howp.com> bob@rush.howp.com (Bob Ames) writes: > /u/tutor/Filecabinet/Profiles/9600bps:A2 > find: bad status-- /u/tutor/Filecabinet/practice/sample6.clf > /u/tutor/.history > find: bad status-- /u/hello > The bad status messages continue for the rest of the /u directory. One of the directories that find goes through right before the "bad status" messages start probably has a ".." that is not the parent that find used to get to the directory. Try this in /u and some other directories: ls -id . */.. Each time you should get the same inode number for each directory. Any mismatch causes find to take the wrong path in trying to get back to where it started from. You can use /etc/link and /etc/unlink to fix. ----------------------------- From: Rahul Dhesi Subject: Re: micro-code upgrade (and VMS vs. Unix stats) Date: 30 Mar 89 20:17:16 GMT To: unix-wizards@sem.brl.mil In article <3623@pixar.UUCP> rta@pixar.UUCP (Rick Ace) writes: >However, it's >probably true that DEC had no idea that things were going to >get worse when they did the upgrade. Doubtful. It's a well-known and unfortunate fact of life that many changes in DEC hardware and software are done mostly to break third-party products. -- Rahul Dhesi UUCP: !{iuvax,pur-ee}!bsu-cs!dhesi ARPA: dhesi@bsu-cs.bsu.edu ----------------------------- From: Rich Salz Subject: Re: Indent posting Date: 30 Mar 89 19:30:50 GMT To: unix-wizards@sem.brl.mil In article <18835@adm.BRL.MIL> gaspar@st-louis-emh2.army.mil (Al Gaspar) writes: =... has done a great job in getting the Berkeley/Sun version =of indent into the public domain. In <1421@yunexus.UUCP> oz@yunexus.UUCP (Ozan Yigit) writes: =I did not do much, except to ask/bug some people, contact its original =author, and those others who worked on it, to clarify its original status, =copyright issues etc. You did a lot. This kind of nitty-gritty detail work can be a real drag, and the work who did is really appreciated! = there is some work =afoot to find ways to babysit the code Keith Bostic of UCB has someone working on it, and I've had anyone who wrote patches, or who volunteered to work on the code, to contact him. When the new version is ready, it will appear in comp.sources.unix /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. ----------------------------- From: "John F. Haugh II" Subject: Re: ranlib: out of memory Date: 30 Mar 89 15:25:01 GMT To: unix-wizards@sem.brl.mil In article <7758@pyr.gatech.EDU> david@pyr.gatech.edu (David Brown) writes: >I don't have source to pick through, unfortunately. Anyone out there in >netland know of a way around this? Any and all help greatly appreciated! Try tsort and lorder. -- John F. Haugh II +-Quote of the Week:------------------- VoiceNet: (214) 250-3311 Data: -6272 | "Do not drink and bake" InterNet: jfh@rpp386.Dallas.TX.US | -- Arnold Swartzenegger UucpNet : !killer!rpp386!jfh +-------------------------------------- ----------------------------- From: Peter da Silva Subject: Re: friendly messages Date: 30 Mar 89 15:41:16 GMT To: unix-wizards@sem.brl.mil Neither of these solutions is correct: In article <1411@moscom.UUCP>, jgp@moscom.UUCP (Jim Prescott) writes: > fprintf(stderr, "%s: %s", Progname, buf); > if (*(buf + strlen(buf) - 1) != '\n') > perror(""); If this is the first time I/O is done, on at least some machines stdio will call isatty(0) to determine if stdout should be unbuffered. It will not save and restore errno. Your program may give such useful advice as: foobar: can't open file barfoo -- Not a typewriter. or: foobar: can't open file barfoo -- Inappropriate ioctl for device. -- Peter da Silva, Xenix Support, Ferranti International Controls Corporation. Business: uunet.uu.net!ficc!peter, peter@ficc.uu.net, +1 713 274 5180. Personal: ...!texbell!sugar!peter, peter@sugar.hackercorp.com. ----------------------------- From: Quentin Fennessy Subject: Booting PWB Unix1.0 to single user Date: 30 Mar 89 20:18:19 GMT To: unix-wizards@sem.brl.mil I previously asked: >I just found an old PDP11/44 in the back of our computer room. Until today >I thought it ran only RSX, but I found an old Unix manual with it. I have been >told that Unix is still on the disk. >I would love to boot this machine, especially with the chance of finding >source, (old, but source nonetheless) on it. >The manual calls it PWB/UNIX Edition 1.0, with dates all in 1977. Well, it has booted, but not to single user. Unfortunately all passwords are history, and all I get is login: When the machine boots, it says something like: rc 1.5 booting pwbe0604 to multi-user and then runs fsck on the system disk. It finds one file system corrupt, tells me to find the sysadmin, and tells me to press HALT. At this point everything I type is merely echoed. If I type , I get a login prompt. I cannot get this to singleuser. If anyone can help me, I would really appreciate it. Thanks a lot for your help. Email is best, and if there is interest I will document my progress for the net. Quentin Fennessy home 617-327-0660 work 617-499-4200 harvard!hub.umb.edu!quentin harvard!hub!umb!quentin ----------------------------- From: Guy Harris Subject: Re: Re^2: Using sigvec & sigcontext Date: 30 Mar 89 23:11:07 GMT To: unix-wizards@sem.brl.mil >I said same contents, not same type. A close look at setjmp will reveal that >is only uses the first seven longwords of the jmp_buf, for exactly the values >shown above. A comment even says "# construct sigcontext"! jmp_buf is >probably only declared as an array, so people don't have to take the address >themselves. Well, it's declared as an array because it antedates "struct sigcontext", because it was done that way in good old V7, and because you're supposed to use the name of the "jmp_buf" in calls to "setjmp", which means that, since C generally supports call-by-value, the value had better be a pointer into the "jmp_buf", which means that (unless "setjmp" is a macro - which the dpANS for C says it must be - *and* inserts the "&" for you), "jmp_buf" must be an array (in fact, said dpANS says it's an array). >> 139 is (was) the `sigcleanup' syscall, used in 4.2BSD to exit from >> signal handlers, and indeed undocumented. It did not take *any* >> arguments; rather, it found a sigcontext structure via the user stack >> pointer pushed by the `chmk' trap, an awful and bloody thing to do, >> which is of course why it was fixed in 4.3BSD.... > >You are right about the argument passing. It does, however, look the same >from user code. Code like > > pushl > chmk $139 > >will do a longjmp (without restoring register contents, as 4.[23] >longjmp does). Which isn't quite the same as "finding the structure via the user stack pointer pushed by the 'chmk' trap"; I read that as meaning that no explicit argument is provided, and that the structure is assumed to be at a specific location on the stack. Instead, "syscall 139" *does* take an argument; it just happens to be passed a little differently. Given that neither it nor "sigreturn" are, in general, usable from machine-independent code ("sigreturn" doesn't load up all the registers, which means you need machine-dependent glue around it anyway, if you want something that amounts to a "machine-independent user-mode context switch" call), I don't see this as being particularly awful or bloody. There *was* some problem with the 4.2BSD "syscall 139"; I don't remember what it was, but as I remember it did *not* exist in the SunOS "syscall 139". >Syscall 139 still exists in the 4.3 I use (MORE/bsd), even though it isn't >listed in sysent. Look in the top of syscall(). That is an awful and bloody >thing to do too. Was it left in only because of longjmp(), which is able to >use sigreturn() instead (more awful and bloody code), or because other >programs depended on it (even more awful and bloody)? "longjmp" in 4.3 *does* use "sigreturn". I presume it was left in so that 4.2BSD binaries would continue to run. >I haven't got sources to SunOS 4.0, but it look like it uses the 4.2 scheme. >It has sigcleanup listed as syscall 139 in sysent, taking no arguments. The >code for sigcleanup looks similar, fetching a sigcontext pointer from the user >stack, followed by a copyin of the necessary parts of the sigcontext, and >assignment to the saved registers in the user structure. SunOS hasn't got >sigreturn either, so those parts of the kernel might be from 4.2. SunOS doesn't have "sigreturn" because it didn't need it; as indicated, "sigreturn" isn't a machine-independent interface to a general "context switch" function, and since making such a function out of "sigreturn" would require additional machine-language glue to load up the other registers anyway, it wasn't deemed worth adding as a "real" system call. That part of the kernel isn't from 4.2, though, except on those versions of SunOS 3.0 ported to the VAX - neither VAX nor Tahoe code works as is on the 68K, the 80386, or the SPARC.... ----------------------------- From: Guy Harris Subject: Re: friendly messages Date: 30 Mar 89 23:27:57 GMT To: unix-wizards@sem.brl.mil >A nice quick 90% solution is a printf-like function that writes to stderr, >prepends the program name to the message, and can append the system error >message. Something like: > if (open(fname, O_RDRW, 0) == -1) > errmsg("Cannot open \"%s\" for read/write -- ", fname); >would output: > prog: Cannot open "somefile" for read/write -- Read-only file system CAREful - you may want to call this function for errors that *don't* cause "errno" to be set. You might want to have some way to indicate whether it should use "errno" or not - or, perhaps, just use the (dp)ANSI C routine "strerror", which takes an "errno" as argument and returns a pointer to the appropriate error message string, and just stick "%s"es into the message string and calls to "strerror" into the argument list. (If your implementation doesn't have "strerror", it's probably a 5-minute job to whip one up, at least under UNIX.) >This makes it fairly painless for the programmer to come up with an >informative message without worrying about the little details. Trying >to use perror to get a nice message is too much work, which is probably >why it isn't used as often as it should be. Yes, but unfortunately burying the call to "perror" in "errmsg" has its own problems. Note also that there are places other than "errno" where errors are reported (by other packages, such as TLI, ONC RPC, database libraries, etc.), often with their own families of error codes and messages, so you may end up having to stick calls to the "return error message" code in *anyway* in some cases.... ----------------------------- From: "Chris A. Anderson" Subject: Locking errors Date: 30 Mar 89 23:03:34 GMT Keywords: lock tables informix c-isam To: unix-wizards@sem.brl.mil I'm having a nasty problem with locking using C-ISAM (v. 1.20) on a Plexus P-95 (SysV.2 K1.7 k80 m68). Specifically, we're getting a errno=34 when a program attempts to open a file. In , this is doubly defined: as ERANGE, and as EDEADLK. Informix thinks that EDEADLK is the most probable definition for errno=34 in this case. Lock table overflow seems to be the most likely reason to get EDEADLK... in , NFLOCK is defined as 100. We've confirmed by testing that lock table over- flow is what the problem is. How do we change NFLOCK? To relink the kernel we'd need some source from Plexus (this may be difficult :-) ). Is there any other way? If we did redefine NFLOCK, what other side-effects could we run into? Any help would be appreciated! Thanks in advance. Chris -- Chris Anderson email: ...!pacbell!sactoh0!utgard!chris QMA, Inc. or: ...!csusac!fenris -------------------------------------------------------------------- ----------------------------- From: "James C. Benz" Subject: uucp killing Date: 30 Mar 89 20:54:39 GMT To: unix-wizards@sem.brl.mil For my peace of mind, is there some way to kill all spooled jobs for a given machine queued for uucp? Let me put that a little more clearly. Suppose I have a machine foobar, and I have ten jobs queued for uucp to foobar. Foobar has just been relegated to the scrap heap, so these jobs will never get sent, or maybe I just discovered an error in the list of files that I sent to foobar. Anyway, I want to kill all jobs queued for sending to foobar. I can sit here and type "uustat -k{idnum}" ten times, which seems like an enormous waste of time (it is - I do it a lot). What I would like to do is something like "uustat -kfoobar*", which doesn't work (can't find job foobar*- not killed). I suppose I could do something like "uustat -sfoobar|shellscript" but then I have to write a shellscript and keep a copy on each machine I work on just for this. Does anyone know of a way to structure the uustat call so I can do this generically? (running ATTsysV on a 3B2) (If this seems trivial, I guess its just because I'm a little bored today :-} ) -- Jim Benz jcbst3@unix.cis.pittsburgh.edu If a modem University of Pittsburgh answers, UCIR (412) 648-5930 hang up! ----------------------------- From: Roy Smith Subject: Re: micro-code upgrade (and VMS vs. Unix stats) Date: 31 Mar 89 02:50:37 GMT To: unix-wizards@sem.brl.mil In article <3623@pixar.UUCP> rta@pixar.UUCP (Rick Ace) writes: > It makes no economic sense for a vendor to support previous versions of > products when the current versions are supersets of their predecessors. > [...] Roy, the best thing you could have done was to demand that DEC > commit to a date (as early as you bargain for) by which they will either > make Rev 7 work or return you to your previous revision level. Rick is, of course, right. In the end, what happened was essentially what Rick suggested; I demanded that if they couldn't fix they they had to put it back to how it was before they started, which eventually they did (fix it, that is). For the record, once the bugs were ironed out, it did work, and has worked fine for years since. Those of you who have followed my rantings over the years know that I'm pretty cynical when it comes to DEC field service; sometimes I get carried away. As a case in point, on the AppleTalk network I try to administer, I don't let anybody plug in a Mac unless they are running the latest version of the system software (or, in the case of 6.0, the latest version that I decree to be working properly). I suppose some people get pissed at me when I demand that they upgrade their system software when what they are running now works fine for them. -- Roy Smith, System Administrator Public Health Research Institute {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@phri.nyu.edu "The connector is the network" ----------------------------- From: Guy Middleton Subject: mk doesn't work the way I expect Date: 31 Mar 89 02:54:49 GMT To: unix-wizards@sem.brl.mil We just got mk, and I tried running this mkfile: PROGS = host addr hostaddr all:V: $PROGS $PROGS: $CC -o $target $target.c I expected this to happen: cc -o host host.c cc -o addr addr.c cc -o hostaddr hostaddr.c Instead, I got this: cc -o host addr hostaddr host addr hostaddr.c I got what I expected when the "all:V: $PROGS" line was removed. Why does it work this way? Am I missing something obvious? -Guy Middleton, University of Waterloo gamiddleton@watmath.waterloo.edu ----------------------------- From: Dave Hammond Subject: Re: friendly messages Date: 30 Mar 89 22:54:36 GMT To: unix-wizards@sem.brl.mil In article <1411@moscom.UUCP> jgp@moscom.UUCP posts his favorite error message printer. I note that for a return value it provides the return from vsprintf. Since error message printers are typically invoked prior to a return, or exit, I opt to have my favorite error printer return -1. While this, perhaps, bastardizes the significance of the function's return value, it (more often than not) makes for convenient error handling: ... if (an_error_occurred) return(errmsg(errcode, "Can't open file %s.", fname)); Obviously this presumes that the calling function normally returns -1 as an its error condition value. Functions which don't employ a -1 error return just void the return from the error printer. -- Dave Hammond daveh@marob.masa.com ----------------------------- End of UNIX-WIZARDS Digest **************************