Mail Delivery Problem
SMTP MAILER
postmaster at [unknown]
Sat Apr 1 08:15:00 AEST 1989
----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 at BRL.MIL
Subject: UNIX-WIZARDS Digest V7#036
To: "baynes" <baynes at drum>
Return-Path: <unix-wizards-request at sem.brl.mil>
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) <Unix-Wizards-Request at BRL.MIL>
To: UNIX-WIZARDS at BRL.MIL
Reply-To: UNIX-WIZARDS at BRL.MIL
Subject: UNIX-WIZARDS Digest V7#036
Message-ID: <8903310245.aa08937 at 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 <jgp at moscom.uucp>
Subject: Re: friendly messages
Date: 29 Mar 89 06:23:02 GMT
To: unix-wizards at sem.brl.mil
In article <3314 at ficc.uu.net> peter at 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 <varargs.h>
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 <stdarg.h>
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 at cs.rochester.edu
{rutgers,ames,harvard}!rochester!moscom!jgp
-----------------------------
From: "David C. Cornutt" <dcornutt at uahcs1.uucp>
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 at sem.brl.mil
In article <3274 at ttrdc.UUCP>, levy at 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 <lmjm at doc.imperial.ac.uk>
Subject: Wanted: POSIX and ANSI C, details and libraries
Date: 28 Mar 89 17:30:00 GMT
Sender: lmjm at doc.ic.ac.uk
To: unix-wizards at 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 at uk.ac.ic.doc Uucp: lmjm at icdoc.UUCP, ukc!icdoc!lmjm
DARPA: lmjm at doc.ic.ac.uk (or lmjm%uk.ac.ic.doc at nss.cs.ucl.ac.uk)
-----------------------------
From: Rene' Seindal <seindal at skinfaxe.diku.dk>
Subject: Re^2: Using sigvec & sigcontext
Date: 28 Mar 89 01:30:32 GMT
Sender: news at freja.diku.dk
To: unix-wizards at sem.brl.mil
chris at mimsy.UUCP (Chris Torek) writes:
> In article <4549 at freja.diku.dk> seindal at 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 <addr of sigcontext or a jmp_buf>
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 at diku.dk).
-----------------------------
From: der Mouse <mouse at mcgill-vision.uucp>
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 at sem.brl.mil
In article <7553 at june.cs.washington.edu>, ka at june.cs.washington.edu (Kenneth Almquist) writes:
> guy at 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 at larry.mcrcim.mcgill.edu
-----------------------------
From: Joseph Boykin <boykin at calliope.encore.com>
Subject: Re: Wanted: POSIX and ANSI C, details and libraries
Date: 29 Mar 89 14:54:18 GMT
Sender: news at encore.com
Followup-To: comp.std.c
To: unix-wizards at sem.brl.mil
In article <746 at gould.doc.ic.ac.uk> lmjm at 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 at encore.com
-----------------------------
From: Roy Smith <roy at phri.uucp>
Subject: Re: micro-code upgrade (and VMS vs. Unix stats)
Date: 29 Mar 89 17:56:02 GMT
To: unix-wizards at sem.brl.mil
dodgson at 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 at 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 at phri.nyu.edu
"The connector is the network"
-----------------------------
From: Barry Shein <bzs at bu-cs.bu.edu>
Subject: Re: namei broken
Date: 29 Mar 89 19:04:59 GMT
To: unix-wizards at 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 <consult at osiris.uucp>
Subject: Re: Implications of large memory systems
Date: 29 Mar 89 17:57:34 GMT
To: unix-wizards at sem.brl.mil
In article <13433 at steinmetz.ge.com> davidsen at 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 <david at pyr.gatech.edu>
Subject: ranlib: out of memory
Date: 29 Mar 89 18:45:15 GMT
To: unix-wizards at 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 at 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 <jimmy at pyrps5>
Subject: Re: Reading raw input from /dev/tty using shell
Date: 29 Mar 89 19:17:17 GMT
Sender: daemon at pyramid.pyramid.com
To: unix-wizards at sem.brl.mil
In article <52 at crdgw1.crd.ge.com> barnett at 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/tty count=1 2>/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 <m5 at lynx.uucp>
Subject: RCS
Date: 29 Mar 89 21:01:36 GMT
To: unix-wizards at 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 <dave at romano.cs.wisc.edu>
Subject: Can I tell if my console output is redirected (TIOCCONS)?
Date: 29 Mar 89 23:22:16 GMT
Sender: news at spool.cs.wisc.edu
Keywords: TIOCCONS, SunOS
To: unix-wizards at 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 at cs.wisc.edu ...!{harvard,rutgers,ucbvax}!uwvax!dave
-----------------------------
From: Dick Dunn <rcd at ico.isc.com>
Subject: processor problems...or just ugliness?
Date: 27 Mar 89 20:00:48 GMT
To: unix-wizards at sem.brl.mil
jfh at 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 <chris at mimsy.uucp>
Subject: Re: RCS
Date: 30 Mar 89 00:07:55 GMT
To: unix-wizards at sem.brl.mil
In article <5372 at lynx.UUCP> m5 at 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 at mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Rahul Dhesi <dhesi at bsu-cs.uucp>
Subject: Re: RCS
Date: 29 Mar 89 23:26:00 GMT
To: unix-wizards at sem.brl.mil
In article <5372 at lynx.UUCP> m5 at 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: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
ARPA: dhesi at bsu-cs.bsu.edu
-----------------------------
From: Roy Smith <roy at phri.uucp>
Subject: Re: namei broken
Date: 30 Mar 89 02:16:40 GMT
To: unix-wizards at sem.brl.mil
In article <29045 at bu-cs.BU.EDU> bzs at 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 at phri.nyu.edu
"The connector is the network"
-----------------------------
From: Patrick Barron <pdb at sei.cmu.edu>
Subject: Problems using ACC ACP5250 under 4.3-tahoe
Date: 29 Mar 89 23:16:31 GMT
To: unix-wizards at 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 <oz at yunexus.uucp>
Subject: Re: Indent posting
Date: 29 Mar 89 22:33:03 GMT
Keywords: indent
To: unix-wizards at sem.brl.mil
In article <18835 at adm.BRL.MIL> gaspar at 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 at 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 <chris at mimsy.uucp>
Subject: Re: Re^2: Using sigvec & sigcontext
Date: 30 Mar 89 04:04:29 GMT
To: unix-wizards at sem.brl.mil
>>In article <4549 at freja.diku.dk> seindal at 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 at freja.diku.dk> seindal at 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 at mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Bob Ames <bob at rush.howp.com>
Subject: find: bad status-- /u/tu
Date: 29 Mar 89 06:56:13 GMT
Followups-To: unix-pc.general
To: unix-wizards at 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 at rush.cts.com or ncr-sd!rush!bob at 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 <chris at mimsy.uucp>
Subject: Re: friendly messages
Date: 30 Mar 89 04:16:50 GMT
To: unix-wizards at sem.brl.mil
In article <1411 at moscom.UUCP> jgp at 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 at mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: Chris Torek <chris at mimsy.uucp>
Subject: Re: Problems using ACC ACP5250 under 4.3-tahoe
Date: 30 Mar 89 04:26:27 GMT
To: unix-wizards at sem.brl.mil
In article <3104 at ci.sei.cmu.edu> pdb at 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 at mimsy.umd.edu Path: uunet!mimsy!chris
-----------------------------
From: "David E. Miran" <dem at uwslh.uucp>
Subject: Re: modems dmf-32s
Date: 29 Mar 89 21:12:31 GMT
To: unix-wizards at sem.brl.mil
In <400 at lclark.UUCP> dan at 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 at cs.wisc.edu
University of Wisconsin (608) 262-0019
465 Henry Mall
Madison, WI 53706
-----------------------------
From: Barry Shein <bzs at bu-cs.bu.edu>
Subject: Re: namei broken
Date: 30 Mar 89 13:32:29 GMT
To: unix-wizards at 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 <daveb at geaclib.uucp>
Subject: 386s and implied OS support
Date: 30 Mar 89 03:01:54 GMT
To: unix-wizards at sem.brl.mil
>From article <18250 at gatech.edu>, by ken at 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 at 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 <rop at neabbs.uucp>
Subject: GALACTIC HACKER PARTY
Date: 29 Mar 89 05:19:45 GMT
To: unix-wizards at 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 <nmm at computer-lab.cambridge.ac.uk>
Subject: Re: Wanted: POSIX and ANSI C, details and libraries
Date: 29 Mar 89 19:31:40 GMT
Sender: news at cl.cam.ac.uk
Posted: Wed Mar 29 20:31:40 1989
To: unix-wizards at 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 at uk.ac.cam.cl
-----------------------------
From: Mike McNally <m5 at lynx.uucp>
Subject: Re: RCS
Date: 30 Mar 89 15:37:06 GMT
To: unix-wizards at sem.brl.mil
In article <16623 at mimsy.UUCP> chris at mimsy.UUCP (Chris Torek) writes:
>Since `co' expands RCS keywords, this would be wrong. For instance:
...
In article <6389 at bsu-cs.UUCP> dhesi at 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 <karl at triceratops.cis.ohio-state.edu>
Subject: Re: RCS
Date: 30 Mar 89 18:27:43 GMT
Sender: news at tut.cis.ohio-state.edu
To: unix-wizards at sem.brl.mil
m5 at 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 <rta at pixar.uucp>
Subject: Re: micro-code upgrade (and VMS vs. Unix stats)
Date: 30 Mar 89 17:02:08 GMT
To: unix-wizards at sem.brl.mil
In article <3729 at phri.UUCP>, roy at 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" <envbvs at epb2.lbl.gov>
Subject: Re: namei broken
Date: 30 Mar 89 19:07:40 GMT
Sender: usenet at helios.ee.lbl.gov
To: unix-wizards at 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 at lbl.gov)
Lawrence Berkeley Laboratory
We don't need no stinking signatures!
-----------------------------
From: Mike Wescott <wescott at ncrcae.columbia.ncr.com>
Subject: Re: find: bad status-- /u/tu
Date: 30 Mar 89 16:30:34 GMT
To: unix-wizards at sem.brl.mil
In article <948 at rush.howp.com> bob at 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 <dhesi at bsu-cs.uucp>
Subject: Re: micro-code upgrade (and VMS vs. Unix stats)
Date: 30 Mar 89 20:17:16 GMT
To: unix-wizards at sem.brl.mil
In article <3623 at pixar.UUCP> rta at 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: <backbones>!{iuvax,pur-ee}!bsu-cs!dhesi
ARPA: dhesi at bsu-cs.bsu.edu
-----------------------------
From: Rich Salz <rsalz at bbn.com>
Subject: Re: Indent posting
Date: 30 Mar 89 19:30:50 GMT
To: unix-wizards at sem.brl.mil
In article <18835 at adm.BRL.MIL> gaspar at 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 at yunexus.UUCP> oz at 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 <bostic at okeeffe.berkeley.edu> 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 at uunet.uu.net.
-----------------------------
From: "John F. Haugh II" <jfh at rpp386.dallas.tx.us>
Subject: Re: ranlib: out of memory
Date: 30 Mar 89 15:25:01 GMT
To: unix-wizards at sem.brl.mil
In article <7758 at pyr.gatech.EDU> david at 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 at rpp386.Dallas.TX.US | -- Arnold Swartzenegger
UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
-----------------------------
From: Peter da Silva <peter at ficc.uu.net>
Subject: Re: friendly messages
Date: 30 Mar 89 15:41:16 GMT
To: unix-wizards at sem.brl.mil
Neither of these solutions is correct:
In article <1411 at moscom.UUCP>, jgp at 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 at ficc.uu.net, +1 713 274 5180.
Personal: ...!texbell!sugar!peter, peter at sugar.hackercorp.com.
-----------------------------
From: Quentin Fennessy <quentin at umb.umb.edu>
Subject: Booting PWB Unix1.0 to single user
Date: 30 Mar 89 20:18:19 GMT
To: unix-wizards at 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 <DEL>,
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 <guy at auspex.uucp>
Subject: Re: Re^2: Using sigvec & sigcontext
Date: 30 Mar 89 23:11:07 GMT
To: unix-wizards at 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 <addr of sigcontext or a jmp_buf>
> 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 <guy at auspex.uucp>
Subject: Re: friendly messages
Date: 30 Mar 89 23:27:57 GMT
To: unix-wizards at 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" <caanders at sactoh0.uucp>
Subject: Locking errors
Date: 30 Mar 89 23:03:34 GMT
Keywords: lock tables informix c-isam
To: unix-wizards at 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 <sys/errno.h>, 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 <sys/params.h>, 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" <jcbst3 at cisunx.uucp>
Subject: uucp killing
Date: 30 Mar 89 20:54:39 GMT
To: unix-wizards at 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 at unix.cis.pittsburgh.edu If a modem
University of Pittsburgh answers,
UCIR (412) 648-5930 hang up!
-----------------------------
From: Roy Smith <roy at phri.uucp>
Subject: Re: micro-code upgrade (and VMS vs. Unix stats)
Date: 31 Mar 89 02:50:37 GMT
To: unix-wizards at sem.brl.mil
In article <3623 at pixar.UUCP> rta at 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 at phri.nyu.edu
"The connector is the network"
-----------------------------
From: Guy Middleton <gamiddleton at watmath.waterloo.edu>
Subject: mk doesn't work the way I expect
Date: 31 Mar 89 02:54:49 GMT
To: unix-wizards at 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 at watmath.waterloo.edu
-----------------------------
From: Dave Hammond <daveh at marob.masa.com>
Subject: Re: friendly messages
Date: 30 Mar 89 22:54:36 GMT
To: unix-wizards at sem.brl.mil
In article <1411 at moscom.UUCP> jgp at 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 at marob.masa.com
-----------------------------
End of UNIX-WIZARDS Digest
**************************
More information about the Comp.unix.wizards
mailing list