UNIX-WIZARDS Digest V5#097
Mike Muuss
Unix-Wizards-Request at arpa.brl
Thu Jul 14 17:45:29 AEST 1988
UNIX-WIZARDS Digest Thu, 14 Jul 1988 V5#097
Today's Topics:
Re: Who dat?
Swapper question.
Re: Interactive Background Processes
Re: where to do line editing?
FNDELAY and FIONBIO -- any difference?
i/o redirection to a non-getty tty?
Re: How do I get RCS?
Re: FNDELAY and FIONBIO -- any difference?
tahoe's driver for uda50
System V.2.2 setuid() broken
Re: Sendmail configuration
Re: Input Line Editing
Bug in 'grep'
Re: Input Line Editing
TAPE/DISK Interface troubles ?? (help!)
Re: tahoe's driver for uda50
cgrep (context-grep)
Re: Input Line Editing In the Kernel
Re: cpio -itv < problems
Re: Input Line Editing
ptrace examples needed
Re: File space allocation/deallocation under Unix (BSD4.x)
Re: cgrep (context-grep)
Re: Input Line Editing
Re: cgrep (context-grep)
Re: where to do line editing?
Re: Input Line Editing
-----------------------------------------------------------------
From: "XMRP50000[jcm]-a.v.reed" <avr at mtgzz.att.com>
Subject: Re: Who dat?
Date: 12 Jul 88 17:30:10 GMT
To: unix-wizards at brl-sem.arpa
In article <2310 at rtech.rtech.com>, daveb at llama.rtech.UUCP (Dave Brower) writes:
< On a single machine, we have a suid server process. A random client
< program wishes to connect and have the server perform some services. The
< server wants to know who the client is before doing anything. They might
< be communicating with sockets, fifos, msgs, or shared memory.
<
< How can the server find out who the client is, in a spoof-proof and
< secure way? On BSD, one can have the server ask the client to create a
< randomly-named file, and the server can see who the owner of the file
< is. On SV, this fails because the client can chown it to be anyone
< else. (The same is true of msgs and shm segments).
<
< Oh wise and knowledgeable Wizards, what is a Way?
On Sys V: Have the client tell you its uid. To verify, open a file
with mode 002 in a directory which is writable only by you, but is
readable by and known to the client. Then write a newly-generated
random content into that file, change the mode of the file to 004,
and chown it to the uid the client gave you. Then have the client
read its content back to you, and compare it with what you wrote
to the file. If they match, the client is who he says he is.
Adam Reed
mtgzz!avr
-----------------------------
From: Frank Mayhar <fmayhar at killer.uucp>
Subject: Swapper question.
Date: 13 Jul 88 06:17:11 GMT
To: unix-wizards at SEM.BRL.MIL
I have a question, related to our development work on a 68020-based SVR2 system:
Why does swapper rack up so much CPU? In spite of the fact that the machine is
completely idle for days at a time, swapper's CPU stays roughly even with the
amount of time that the system has been up, to within about a minute. What
gives, and how can we change this? The machine will run as an intelligent
peripheral for a mainframe, and we're trying to maximize performance. If anyone
can help, please reply by email to the Internet address if possible, otherwise
to this machine.
Thanks in advance.
--
Frank Mayhar UUCP: ..!{ihnp4,dj3b1}!killer!fmayhar
ARPA: Frank-Mayhar%ladc at BCO-MULTICS.ARPA
USmail: 2116 Nelson Ave. Apt A, Redondo Beach, CA 90278
Phone: (213) 371-3979 (home) (213) 216-6241 (work)
-----------------------------
From: Greg Woods <woods at gpu.utcs.toronto.edu>
Subject: Re: Interactive Background Processes
Date: 13 Jul 88 04:11:05 GMT
Checksum: 11115
To: unix-wizards at SEM.BRL.MIL
In article <8029 at alice.UUCP> wilber at alice.UUCP writes:
>As a non-wizard (posting under false pretenses, I guess) it seems to me that
>if you have a version of Unix without job control or layers or the like the
>"poor man's solution" to this problem is to fire up Emacs, make as many shell
>buffers as you need, and run whatever you want in each one. Of course the
>background process can't keep running after you log out.
>
>Bob Wilber Work: UUCP: {allegra, mtune, ihnp4}!gauss!wilber
> ARPA: wilber at research.att.com
Unfortunately, a Unix without job control, layers, or such will not
provide the system facilities required for emacs to do the same.
Fortunately, one of these "features" usually exists in every version of
Unix, though that doesn't mean emacs will work with it properly.
Unfortuantely, only a true window manager for X or NeWS, or layers (not
shell-layers) on a DMD terminal, or something similar, are easy enough
to use. None of these are usefull on a dumb terminal at 1200 baud,
though layers is nearly so, it's just the terminal isn't very cheap nor dumb.
--
Greg Woods.
UUCP: utgpu!woods, utgpu!{cpcc, ontmoh, ontmoh!cpcc, tmsoft!cpcc}!woods
VOICE: (416) 242-7572 [h] LOCATION: Toronto, Ontario, Canada
-----------------------------
From: Karl Kleinpaste <karl at loquat.cis.ohio-state.edu>
Subject: Re: where to do line editing?
Date: 13 Jul 88 02:30:06 GMT
To: unix-wizards at SEM.BRL.MIL
al at gtx.com writes:
[line editing as in ksh is mighty neat, but might be better done
in the kernel, notwithstanding arguments against user interfaces
being implemented there. Alternate suggestion is to create a
library such as curses, but has the drawback of requiring explicit
programming to put it to use.]
Comments, flames? Anybody done it, meant to do it, thought about
it, rejected it?
I did it once. I created a thing called liblinedit.a, which consisted
of a few files which made up my own incarnation of a line editor.
This was the editor which I attached to csh lo these many years ago.
It was written very generally so as to be able to attach it to
anything that wanted to do line-at-a-time input. Due to my inability
to distribute the thing, it never got much exposure outside local
systems where I supported my csh. Paul Placeway (cf. tcsh) has
occasionally made noises about turning the tcsh editor into a linkable
library, but I don't think he's ever actually done it.
It's very doable, not particularly tough, really no big deal once
you've taken care of a few details. Just make sure that it has a
single entry point that looks, feels, and smells like an ordinary
read() call except that it does whizbang things inside. I started
from Ken Greer's tenex stuff originally distributed in October 1984.
It occurs to me that ksh's editing library may even include a way to
build a libedit.a suitable for such usage.
--Karl
-----------------------------
From: Steven Grimm <koreth at ssyx.ucsc.edu>
Subject: FNDELAY and FIONBIO -- any difference?
Date: 12 Jul 88 17:47:17 GMT
Sender: usenet at saturn.ucsc.edu
To: unix-wizards at SEM.BRL.MIL
Do these calls do anything different?
----
one = 1;
ioctl(fd, FIONBIO, &one);
----
fcntl(fd, F_SETFL, FNDELAY);
----
>From what little documentation I could find, it looks
like these two do the same thing. Is that correct?
---
These are my opinions, and in no way reflect those of UCSC, which are wrong.
Steven Grimm Moderator, comp.{sources,binaries}.atari.st
koreth at ssyx.ucsc.edu ...!ucbvax!ucscc!ssyx!koreth
-----------------------------
From: rwl at umree.uucp
Subject: i/o redirection to a non-getty tty?
Date: 12 Jul 88 16:20:00 GMT
Nf-ID: #N:umree.UUCP:29500001:000:1279
Nf-From: umree.UUCP!rwl Jul 12 11:20:00 1988
To: unix-wizards at SEM.BRL.MIL
INTRO
I would like to allow i/o redirction to some graphics terminals & other
devices for display purposes from some regular ascii terminals.
e.g. "graphics_program > /dev/ttyxx"
THE PROBLEM
If the getty is on, it often munches the input mistaking it for a login.
If the getty is turned off, nothing gets through. (Note: I have been able to
output with the getty off with a setuid root program that explicitly opens the
device, but I would like just to use the normal csh i/o redirection: > & < .)
The present *kludge* (see below) requires manual intervention after each reboot.
THE PRESENT KLUDGEY SOLUTION (from a public domain cad package from ucb)
(I'm not complaining, its crude but effective...)
Login with user id "sleeper", which runs a simple C program which sleeps.
The guts of the C program are:
chmod(ttyname(1),0666);
while(1) sleep(200000);
Here's the line from the password file:
sleeper::199:199:Beautiful Dreamer,,,,0018:/usr/cad:/usr/cad/bin/sleeper
(There's also a .hushlogin file in the home dir.)
A BETTER SOLUTION
Does anyone know how to do this elegantly? I'd even settle for crudely
if it was automated.
Please reply directly & I'll be happy to summarize replies back to the group.
advTHANKSance,
Wayne Little
rwl at umree.UUCP
rwl at UMRUNIXA.BITNET
-----------------------------
From: James Van Artsdalen <james at bigtex.uucp>
Subject: Re: How do I get RCS?
Date: 13 Jul 88 08:10:45 GMT
To: unix-wizards at brl-sem.arpa
In article <433 at vector.UUCP>, chip at vector.UUCP (Chip Rosenthal) writes:
> Do any systems with anon uucp have this available?
bigtex does for TB+ users. But RCS doesn't seem to work. I assume
it's "diff" incompatibilities. In particular, "co" fails when
retrieving any but the current revision: "ci" seems to create corrupt
archives. Let me know if anyone has a fix.
phone: 512-327-8951
speed: Trailblazer/PEP
login: nuucp (no password)
index: /usr3/Index
RCS is /usr3/rcs/RCS.tar.Z
--
James R. Van Artsdalen ...!ut-sally!utastro!bigtex!james "Live Free or Die"
Home: 512-346-2444 Work: 328-0282; 110 Wild Basin Rd. Ste #230, Austin TX 78746
-----------------------------
From: Chris Torek <chris at mimsy.uucp>
Subject: Re: FNDELAY and FIONBIO -- any difference?
Date: 13 Jul 88 13:15:49 GMT
To: unix-wizards at brl-sem.arpa
In 4.3BSD, at least, FIONBIO is implemented as
case FIONBIO:
... fset(fd, FNDELAY, *(int *)data)
break;
and FIOASYNC as
... fset(fp, FASYNC, *(int *)data)
so the answer is No, no difference at all.
--
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: Yedidya Israel <yedidya at bimacs.bitnet>
Subject: tahoe's driver for uda50
Date: 13 Jul 88 10:52:30 GMT
Sender: daemon at ucbvax.berkeley.edu
To: unix-wizards at SEM.BRL.MIL
We are running a uVAX II with two disk controllers. One suppors two
rd53 disks + two rx50 diskette drives, the other supports a CDC disk
that simulates uda50. We have some problems of hanging-up and been
told that BSD- uda50 driver is full of bugs which were (partly) solved
in the 4.3-tahoe version. Can anyone send me the source code of the
4.3-tahoe's version of the driver? Note that we have a licence of
berkeley.
+---------------------------------------------------------------------+
| Israel Yedidya, Math & CS Department, Bar-Ilan U, Ramat-Gan, ISRAEL |
+---------------------------------------------------------------------+
| BITNET: yedidya at bimacs |
| ARPA: yedidya%bimacs.bitnet at cunyvm.cuny.edu |
| CSNET: yedidya%bimacs.bitnet%cunyvm.cuny.edu at csnet-relay |
| UUCP: uunet!mcvax!humus!bimacs!yedidya |
+---------------------------------------------------------------------+
-----------------------------
From: Boyd Roberts <boyd at basser.oz>
Subject: System V.2.2 setuid() broken
Date: 13 Jul 88 01:27:33 GMT
To: unix-wizards at SEM.BRL.MIL
I'm root and I run a non-root setuid executable. Then I want
to fork() a shell and do the usual:
setuid(getuid())
Of course, I get EPERM, because setuid() is broken. Now is this
a generic System V bug. I think it is. Clarification please?
I think what I have is pretty generic SysV. V8 & 32V do the _right_
thing, they work. System V has, of course, a mind of it's own.
I _know_ it's a bit silly, but it should _work_. UNIX did.
Boyd Roberts boyd at basser.cs.su.oz
boyd at necisa.necisa.oz
``When the going gets wierd, the weird turn pro...''
-----------------------------
From: Johan Vromans <jv at mhres.mh.nl>
Subject: Re: Sendmail configuration
Date: 12 Jul 88 13:34:03 GMT
To: unix-wizards at brl-sem.arpa
>From article <1158 at ora.UUCP>, by tim at ora.UUCP (Tim O'Reilly):
> In article <1330 at swlabs.UUCP>, jack at swlabs.UUCP (Jack Bonn) writes:
>> Just where does one go to read all the intricacies of sendmail
>> configuration? Does one of the Nutshell guides cover this
>> (having heard good things about them)?
>
> We're planning to do a book on sendmail, but alas, it won't
> be available until the late fall. By then you'll know all
> about it! :-)
... or sendmail will be wiped out by the coming of new mailers like
smail3.1 or Zmailer ...
Advise: don't write a manual - write a history book :-).
--
Johan Vromans | jv at mh.nl via European backbone
Multihouse N.V., Gouda, the Netherlands | uucp: ..{uunet!}mcvax!mh.nl!jv
"It is better to light a candle than to curse the darkness"
-----------------------------
From: "Chris Calabrese[rs]" <cjc at ulysses.homer.nj.att.com>
Subject: Re: Input Line Editing
Date: 13 Jul 88 16:45:04 GMT
To: unix-wizards at SEM.BRL.MIL
In article <9666 at eddie.MIT.EDU>, nessus at wonko.mit.edu.UUCP writes:
>
> Putting line editing in the shell is wrong, because it should work in
> all programs and be consistent. Putting it in the kernal is gross.
> Thus, the right place to put it is precisely where Bob Pendleton wants
> to put it -- in a process which gets input from the user and feeds
> edited input to the user's other programs. If needed, mods to the
> kernal and convention, however, should be made to make this as easy
> and efficient as possible.
You are assuming that
a) _everyone_ wants line editing in _every_ program
what about the built in editors on the
layers and NeWS windowing systems?
b) _everyone_ wants the same line editing
I use vi, but that's only because I'm used to it
after a few years. Most people want modeless editing
> The same is true for output. This "termcap" stuff is a crock. There
> should be a process which gets the output from programs, processes it,
> and displays it. This process should be responsible for managing the
> screen, and keeping track of what is on it for an entire login. Every
> program having to clear the screen when it is started, so it knows
> what state the screen is in, and having to have this big library
> compiled in, is bogus. The ITS operating system knew better than this
> decades ago. It had a decent virtual terminal system. So did MIT's
> version of Tops-20 (it was in the kernal, however).
Clearing the screen on every invocation??? What about non-interactive
processes??? Or interactive processes getting their input from a
redirect/pipe/socket/stream??? O.K., you probably were referring to
interactive programs.
It is reasonable to have virtural terminal handling
done in a seperate process (NeWS, layers, X), or within the
process (curses, TAM (developed for the AT&T 3b1 - O.K. it's not
made anymore, but with shared memory libraries, TAM _way_ outperforms
curses, and is much easier to use)). Either way, however, something
like termcap or terminfo will have to be used, even if the programmer
doesn't have to know about it. Actually, if you use curses, the programmer
doesn't have to know about it, and there's no reason not to use shared libraries
for sane performance.
> In fact, X currently does much of this. It should be made to be more
I hate X!!!!!!!!! It's the _biggest_ pain in the butt ever invented
for programmers, and it has the performance of pig. Please don't
lock me into it! Just my personal opinions of course, but read
comp.windows.news for more info on X bashing. :-) :-).
As for editors, I'd love to see one included in the terminal driver.
Shouldn't be too difficult, the code's already there for ksh - of course,
if it's used only people with AT&T source licences will be able to make
use of the mods, but then, only people with this licence will be able
to install them, anyway.
--
Christopher J. Calabrese
AT&T Bell Laboratories
ulysses!cjc
-----------------------------
From: Guy Harris <guy at gorodish.sun.com>
Subject: Re: Input Line Editing
Date: 13 Jul 88 17:29:27 GMT
Sender: news at sun.uucp
To: unix-wizards at SEM.BRL.MIL
> Putting line editing in the shell is wrong, because it should work in
> all programs and be consistent. Putting it in the kernal is gross.
> Thus, the right place to put it is precisely where Bob Pendleton wants
> to put it -- in a process which gets input from the user and feeds
> edited input to the user's other programs. If needed, mods to the
> kernal and convention, however, should be made to make this as easy
> and efficient as possible.
Yes. You can almost do what you want with EMACS; the problem is that EMACS has
no way of finding out about "ioctl"s done on the tty, so it can't do the moral
equivalent of turning off echoing or canonicalization.
> In fact, X currently does much of this. It should be made to be more
> well-integrated, however. Every program should know about X, so no
> program has to worry about managing the screen on its own. Perhaps X
> should have input line editing added to it.
Huh? What do you mean by "X"? If you're referring to the server for the X11
Window System, it should definitely *not* "have line editing added to it." The
X11 server is supposed to deliver extremely RAW key events to its clients, so
that the clients aren't obliged to undo any "intelligence" that the server
adds. What if the client *isn't* using the keyboard as a "normal"
terminal-style keyboard?
It would be nice to have, say, an Xt widget that performed the same function as
an EMACS shell window or an Andrew shell window; there may well already be such
a beast. The underlying editor code used by this could be the same as the
editing code used by other widgets, such as a "text field" widget, or should at
least provide the same general sort of behavior.
As for "every program should know about X", well, "cat" shouldn't know about X;
it should only know about writing output to a file descriptor. The file
descriptor goes to a pseudo-terminal (or moral equivalent); the output goes to
an X11 client program, which displays it on the screen by sending requests to
the X11 server. "cat" doesn't know about X; "xterm" does.
> There should also be a version of X that runs in a limitted form, but
> supports the most basic features, on a normal, dumb terminal, so you
> don't *have* to have a workstation to use programs that don't need
> one.
One of the "most basic features" of X11 is the ability to draw things such as
lines, and curves, and so on and so forth, with pixel-level resolution. I
would be very surprised to hear about *ANY* X11 client that could live with the
minimum set of X11 requests that could be implemented on a "dumb terminal", if
by that you mean a 24x80 ASCII terminal with a positionable cursor. To be
specific, I doubt you'd be able to run "xterm" - a program that emulates a
"dumb terminal" - on this mythical "X on a VT100" that people periodically
request.
Another way of putting this is that I know of no X11 client program that
"doesn't need a workstation" or, at least, doesn't need a bit-mapped display
terminal with a pointing device. If there is such a beast, it's an exception.
-----------------------------
From: Doug Alan <nessus at wonko.mit.edu>
Subject: Re: Input Line Editing
Date: 13 Jul 88 19:08:32 GMT
Sender: uucp at eddie.mit.edu
To: unix-wizards at brl-sem.arpa
In article <10443 at ulysses.homer.nj.att.com>
cjc at ulysses.homer.nj.att.com (Chris Calabrese[rs]) writes:
> In article <9666 at eddie.MIT.EDU>, nessus at wonko.mit.edu.UUCP writes:
> > Putting line editing in the shell is wrong, because it should work in
> > all programs and be consistent. Putting it in the kernal is gross.
> > Thus, the right place to put it is precisely where Bob Pendleton wants
> > to put it -- in a process which gets input from the user and feeds
> > edited input to the user's other programs. [...]
> You are assuming that
> a) _everyone_ wants line editing in _every_ program
> what about the built in editors on the
> layers and NeWS windowing systems?
I *do* want editing in *every* program (that takes input as command
lines). If someone else doesn't want editing, they don't have to use
it. No one is forcing anyone to type the editing control characters.
> b) _everyone_ wants the same line editing
> I use vi, but that's only because I'm used to it
> after a few years. Most people want modeless editing
I certainly am not assuming that everyone wants the same line editing.
Anyone should be able to chose whatever program they want to do their
line editing, and the standard program should be configurable.
However, parts of Unix should be redesigned a bit to know that such a
process will be there, and interfaces should be designed and
standardized so that programs that need to, can communicate with the
input editor process, and whatever kernal mods needed should be made
so that the input editor can do things like find out what the current
working directory of the process it's feeding input to is, and
whatever else it needs to do for it to work well.
> I hate X!!!!!!!!! It's the _biggest_ pain in the butt ever invented
> for programmers, and it has the performance of pig. Please don't
> lock me into it! Just my personal opinions of course, but read
> comp.windows.news for more info on X bashing. :-) :-).
Well, I'm no Xpert, but I believe a lot of the problem with
programming X is that there has not been a standard toolbox. A lot of
people's experience with programming X has been with the low level
facilities that were initially provided. I believe that a much higher
level toolbox has or is being standarized that makes it much more of a
pleasure to program. Regarding performance, I use X for many hours
every day, and its performance is fine. It's not the fastest thing in
the world, but it is certianly acceptible, and I'm not using an X
whose drivers have been optimized for the hardware. I've seen
implementations of X that book. They are running on different
machines, where the drivers have been optimized for the display
hardware. I don't believe that there is anything inherently
incredibly inefficient in the design of X. Some implementations just
aren't optimized for their hardware.
Regarding not locking you into X... Well, then, you better come up
with something better and put it into the public domain. And you
better do it awfully darn quickly! Or it will be too late. Actually,
don't bother -- it's already too late.
|>oug /\lan
-----------------------------
From: Andrew Arensburger <arensb at cvl.umd.edu>
Subject: Bug in 'grep'
Date: 13 Jul 88 16:45:01 GMT
To: unix-wizards at SEM.BRL.MIL
There is a bug in 'grep': if the input file does not end with a
newline, and your pattern is in the last line, 'grep' will not find it.
The routine 'execute', which reads in lines from the input file and compares
them to the pattern should be changed from
execute(file)
char *file;
{
register char *p1, *p2;
register c;
[...]
for (;;) {
lnum++;
p1 = linebuf;
while ((c = getchar()) != '\n') {
if (c == EOF) {
[...]
return;
}
[...]
to
execute(file)
char *file;
{
register char *p1, *p2;
register c;
char eof; /* 'end-of-file' flag */
[...]
for (eof = 0; !eof;) { /* While not end of file */
lnum++;
p1 = linebuf;
while ((c = getchar()) != '\n') {
if (c == EOF) {
[...]
eof = 1;
break;
}
[...]
which neatly circumvents the problem.
/AA/
-----------------------------
From: Barry Shein <bzs at bu-cs.bu.edu>
Subject: Re: Input Line Editing
Date: 13 Jul 88 19:51:23 GMT
To: unix-wizards at brl-sem.arpa
One thing about fancy input line editing: it should probably be either
everywhere or nowhere (I distinguish "fancy" only because Unix,
particularly BSD, already has some line editing, such as erase-word.)
What I don't like about just putting it into a shell is that it then
conflicts with habits when using a simple program which just does
reads, a human interface issue. I also like the idea that any
programmer's program (even a neophyte's own) tends to work more or
less as well as the shell on really visible things like input editing.
If there's one criticism I have of TOPS-20's fancy input editing it's
that it was incredibly baroque for the programmer, and rarely
available to the higher level language programmer in any reasonable
way (eg. thru the languages' std input methods, like scanf().) It may
have been the cat's meow in some's eyes in effects, but it sure wasn't
very well thought out in terms of letting (mortal) applications
programmers near it, so vanilla applications tended to look kind of
klunky and brain-damaged (and that OS had no particular interest in
device independance tho one could code anything if they had the
patience to run thru enough JSYS's to get the effect they wanted.)
I haven't looked at the Unix COMND routines from, I believe, Columbia,
perhaps I (we) should.
The other question is, if it's done as an intermediate process how
does the process know when to step out of the way because a newly
started job is doing its own style of input editing? (yes, I'm bracing
myself for the answer...)
-Barry Shein, Boston University
-----------------------------
From: Howard Leadmon <howardl at wb3ffv.uucp>
Subject: TAPE/DISK Interface troubles ?? (help!)
Date: 13 Jul 88 16:56:05 GMT
Keywords: tape disk unix microport problems
To: unix-wizards at SEM.BRL.MIL
I have a very interesting situation over here that confuses the daylights
out of me, and hope somebody might have some ideas. I have just installed
a Bell Technoliges tape drive in my 80386 machine (60meg 1/4" streamer)
and this is were the problem begins. When attempting to backup the data
from my 130meg PRIAM drive, the drive will generate errors about accessing
the disk, and of course UNIX get's ticked off at that and goes belly up on
me. After carefully observing the problem I have discovered that it only
happens when both the tape unit and the hard disk are both attempting an
access that the same time (all interupts are OK). To verify this I used tar
(not Bell's special utilites) with a very small blocking factor, and this
made things slow.... but it reduced the chance of conflict. I haven't come
up with a way that I can start a backup without having both devices doing an
access at the same time, but this it what I have been able to deduce from
using different modes. Anyway what happens it that the HD goes through the
restart and calibrate procedure (as described by Priam) when the error
occours, and UNIX won't tolerate the delay. I have done very very heavy
accessing on the drive, and handle a lot of mail/news, and the drive works
without a flaw unless I use the tape drive. Also I have made backups on
floppy before, but backing up a 100meg of data on floppy is terrible!!
Does anybody have any idea as to what might cause this conflict, and if
so any possible solution ?? I really need to get the backup working, as
the potential data loss from not backing up is scary... [help!]
-------------------------------------------------------------------------------
UUCP/SMTP : howardl at wb3ffv | Howard D. Leadmon
PACKET : WB3FFV @ W3ITM | Fast Computer Service, Inc.
IP Address: 44.60.0.1 | P.O. Box 171
Telephone : (301)-335-2206 | Chase, MD 21027-0171
-----------------------------
From: Chris Torek <chris at mimsy.uucp>
Subject: Re: tahoe's driver for uda50
Date: 13 Jul 88 19:03:15 GMT
To: unix-wizards at brl-sem.arpa
In article <8807130955.AA21029 at jade.berkeley.edu> yedidya at bimacs.BITNET
(Yedidya Israel) writes:
>... uVAX II with two disk controllers ... We have some problems of
>hanging-up and been told that BSD- uda50 driver is full of bugs which
>were (partly) solved in the 4.3-tahoe version.
The 4.3BSD-tahoe uda50 driver is (mostly) mine. The only MicroVAX to
which I have access has only one controller, so I have not been able
to test this mysterious hang problem. I have had one report that my
driver solves the problem, and one that it does not.
>Can anyone send me the source code of the 4.3-tahoe's version of the
>driver?
Before you can use the 4.3-tahoe driver, you need the new disk label
code. To use the disk label code you need the new diskerr() routine.
You also need the new generic raw I/O code. To use this you need the
new VM code. To use the changes to the VM code, you need the new
core kernel code. To use the new kernel code, you need the new machine
dependent code, and the new file system code. And so on, and on....
Note that you can run the new kernel with the old binaries, modulo
the following exceptions (these are the ones I can think of offhand):
/etc/disklabel (new) (needs C library additions)
/etc/fsck (understands new fields in superblock; converts
to and from new-style file system cylinder groups)
/etc/newfs (builds new-style file systems, installs disk
labels) (NB: kernel still supports old style FS)
/etc/config (I think)
/bin/make (VPATH now works and ${MACHINE} is new)
Nothing else comes straight to mind, although there are various bug
fixes in the compilers that could conceivably be important.
--
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: Andrew Arensburger <arensb at cvl.umd.edu>
Subject: cgrep (context-grep)
Date: 13 Jul 88 19:09:42 GMT
Keywords: grep
To: unix-wizards at SEM.BRL.MIL
I'm thinking of writing a utility called cgrep, which works just
like grep, but instead of writing out just the line on which the pattern
was found, would write out a couple of lines surrounding the line in
question.
Has anyone implemented this, or am I going to have to write it?
/AA/
-----------------------------
From: Joe Bob Willie <haugj at pigs.uucp>
Subject: Re: Input Line Editing In the Kernel
Date: 13 Jul 88 16:17:22 GMT
To: unix-wizards at brl-sem.arpa
[ In a previous article Doug Alan expounded on the virtues of kernel support
for input line editting and virtual terminal output. ]
this is possible where the number of terminals which are supported is
limited to some subset. a unix system may have any number of different
terminals with their different methods of handling features connected.
the only microcomputer operating system i've seen which had a virtual
screen was the p-system. it handled screen updates by homing and
redrawing the entire screen. ibm's (and others) large machine operating
systems can afford to redraw the screen since terminal i/o is so damned
fast (for non-serial devices, such as coax).
for the typical unix system with it's hudge-podge of devices and slow
serial i/o, i don't believe virtual terminal support really belongs
in the kernel.
- john.
--
John "Evil USENET User" F. Haugh II HECI Exploration Co, Inc., Dallas
UUCP: ...!killer!rpp386!jfh jfh at rpp386.UUCP :DOMAIN
**** Trivia question of the day: VYARZERZIMANIMORORSEZASSEZANSERAREORSES? ****
"You are in a twisty little maze of UUCP connections, all alike" -- fortune
-----------------------------
From: Will Nelson <will at cygnet.cygnetsystems>
Subject: Re: cpio -itv < problems
Date: 13 Jul 88 22:52:06 GMT
Keywords: pwd .. getcwd cpio "sh: pwd: cannot open .."
To: unix-wizards at SEM.BRL.MIL
In article <913 at rivm05.UUCP>, ccea3 at rivm.UUCP (Adri Verhoef) writes:
> Bug: `cpio' does not work when it can't open one of it's parent directories.
> Repeat-by:
> $ id
> uid=104(ccea3) gid=101(cce)
> $ cd /tmp
> $ mkdir tst1; cd tst1
> $ mkdir tst2; cd tst2
> $ chgrp bin ..
> $ chown bin ..
> $ pwd
> /tmp/tst1/tst2
> $ touch bugs.cpio
> $ cpio -itv < bugs.cpio
> sh: pwd: cannot open ..
> $ ls -ld . ..
> drwxr-x--- 2 ccea3 cce 32 May 31 22:04 .
> drwxr-x--- 3 bin bin 48 May 31 22:04 ..
>
> `cpio' should only display the contents of the file "bugs.cpio",
> but it can't open one of its parent directories
> and the file's contents will not be displayed.
> Has this been fixed in any release? (On System V.3.1 it still isn't.)
>
> Adri verhoef,
> mcvax!rivm!a3
See the Summary.
--
Will Nelson uucp: {decvax!decwrl}!pyramid!oliveb!cygnet!will
Cygnet Systems, Inc.
601 West California Avenue
Sunnyvale, CA 94086-4831 (408) 773-0770
-----------------------------
From: Guy Harris <guy at gorodish.sun.com>
Subject: Re: Input Line Editing
Date: 13 Jul 88 23:29:51 GMT
Sender: news at sun.uucp
To: unix-wizards at brl-sem.arpa
> > Thus, the right place to put it is precisely where Bob Pendleton wants
> > to put it -- in a process which gets input from the user and feeds
> > edited input to the user's other programs.
>
> You are assuming that
> a) _everyone_ wants line editing in _every_ program
> what about the built in editors on the
> layers and NeWS windowing systems?
As I read what he said, he was referring to something such as an EMACS window
or an Andrew typescript window.
I don't know what "the built-in editor on the NeWS windowing system" is (I
haven't seen any such editor); were there such an editor in NeWS, I might
expect it to resemble those in an EMACS window or an Andrew typescript window,
given who wrote 1) one version of UNIX EMACS, 2) a very large chunk of the
original Andrew system, and 3) most of NeWS.
I assume that the editor on the "layers" system is similar, in concept, to the
one in an EMACS or Andrew typescript window, in that it takes what you type and
treats them as text to be typed into an editor buffer or as editor commands,
and, when you type a <RETURN>, sends the current line as a pre-canonicalized
lump to the application, bypassing any "normal" tty driver stuff.
Given that, I see an editor such as the one purported to come with NeWS and the
one in layers as being precisely what he wanted.
> b) _everyone_ wants the same line editing
> I use vi, but that's only because I'm used to it
> after a few years. Most people want modeless editing
OK, then the aforementioned built-in editors might lose as well if they can't
be made to look like EMACS, "vi", or whatever your favorite editor is. I agree
that this is a problem, but unless your editor is sufficiently programmable
that it can look like any other editor (EMACS may well be this programmable)
about all you can do is try to make it possible to use several different
flavors of editor for this. I don't see that he required that only *one* such
editor exist.
> It is reasonable to have virtural terminal handling
> done in a seperate process (NeWS, layers, X), or within the
> process (curses, TAM (developed for the AT&T 3b1 - O.K. it's not
> made anymore, but with shared memory libraries, TAM _way_ outperforms
> curses, and is much easier to use)). Either way, however, something
> like termcap or terminfo will have to be used, even if the programmer
> doesn't have to know about it.
No, not necessarily. If *all* tty-oriented programs are run inside some
"virtual terminal" window, be it a layers window, an "xterm" window, a
"shelltool" window, a "psterm" window, an "nterm" window, a BSD "window"
window, etc., and all of those windows emulate the exact same terminal, you
don't need something like termcap or terminfo, since all "terminals" that a
regular program would talk to would be the same - they'd never talk to a real
terminal.
Now, of course, the dumb-terminal windowing programs such as BSD's "window",
which support multiple windows on a cursor-addressible terminal by running
programs inside pseudo-ttys, treating output written to those pseudo-ttys as
requests to update a virtual screen, and displaying those virtual screens (or
parts of them) on the physical screen, would probably need something such as
"termcap" or "terminfo" to know how to update the physical screen (if it uses
"curses" to handle the screen, "curses" then nees "termcap" or "terminfo").
> As for editors, I'd love to see one included in the terminal driver.
Gak. *I*'d* love to see all line editing *removed* from the terminal driver,
if by that you mean the thing in the kernel that responds to characters
arriving over a serial line or pseudo-tty. I'd like to see it done in a
program, just as Doug suggested.
One advantage of *NOT* doing it in the kernel is that, as you pointed out, not
everybody *does* want the same editor; if you put it in the kernel, users can't
generally just replace it easily.
-----------------------------
From: "Theodore Y. Ts'o" <tytso at athena.mit.edu>
Subject: Re: Input Line Editing
Date: 14 Jul 88 02:26:23 GMT
Sender: daemon at bloom-beacon.mit.edu
To: unix-wizards at brl-sem.arpa
One problem with putting the input line editor (ile) where it is is that
you don't always want to be able to step back through ALL the lines that
were typed to that tty. For example, if you started editing a file
using /bin/ed (or some other interactive program), and typed hundreds
of "n", "p", "i", "a", and "s/foo/bar/" commands, when you exited to
the shell, do you really want to step through those hundreds of /bin/ed
commands? The shell isn't going to do anything useful with them. Want
I want to do is step back to the last *shell* commands, not necesarilly
the last line I typed.
Now, you might say that this is a "inconsistent user interface". But I
find that having the shell step through only shell commands is a lot
more friendlier to the user. I use a csh with a line editor hacked in,
and I've been very satisified with the result. This is the csh which
is in use at MIT Project Athena, and our users in general like it a lot.
- Ted
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Theodore Ts'o mit-eddie!mit-athena!tytso
3 Ames St., Cambridge, MA 02139 tytso at athena.mit.edu
If it's for real, it isn't!
-----------------------------
From: Danny Backx <dannyb at kulcs.uucp>
Subject: ptrace examples needed
Date: 13 Jul 88 12:58:39 GMT
Keywords: ptrace unix examples
To: unix-wizards at brl-sem.arpa
I am looking for simple example programs illustrating the use of the ptrace
system call.
I have tried to get the examples in M.J. Bach's book to work, but failed.
(Anybody knows why ?)
Any working program would be good. I can work on Sun's (SunOS 3.4), VAXen
(Mt.Xinu 4.3), and Sequent (DYNIX 3.0.8).
Any help is appreciated.
Danny
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Danny Backx | mail: Katholieke Universiteit Leuven
Tel: +32 16 200656 x 3544 | Dept. Computer Science
E-mail: dannyb at kulcs.UUCP | Celestijnenlaan 200 A
... mcvax!prlb2!kulcs!dannyb | B-3030 Leuven
dannyb at blekul60.BITNET | Belgium
-----------------------------
From: Randy_Davis <rjd at occrsh.att.com>
Subject: Re: File space allocation/deallocation under Unix (BSD4.x)
Date: 13 Jul 88 13:38:28 GMT
Keywords: Unix, BSD, File, Delete
To: unix-wizards at SEM.BRL.MIL
In article <9662 at eddie.MIT.EDU> rich at eddie.MIT.EDU (Richard Caloggero) writes:
: If you create a directory "d", then create a file "d/f" 1 megabyte
:long (big), then "rm d/f", is it true that the space remains allocated
:to directory "d" and cannot be garbage collected or otherwise reclaimed
:until another file is created in directory "d" or "d" is deleted? If this is
true, why? What good does it do to delete files, say, in your home directory
:(if, for example, disk resources are low and you system administrator
:keeps hounding you to "clean up your directory")?
: -- Rich (rich at eddie.mit.edu).
When you remove the file, the space taken by the file *contents* is reclaimed,
i.e., the 1 megabye above is available for system use again. The 16 bytes
(for System V) taken by the file entry in the directory "file" is *not*
reclaimed unless you remove the directory.
To explain the directory part further: if you make the directory then ls -al
the directory, you will see that the directory entry, ".", takes up 32 bytes
of space; 16 bytes for the "." entry, and 16 bytes for the ".." entry (you can
check this under System V via the 'od -c .' command). If you create a file
under this directory, the directory "file" will increase by 16 bytes to 48
bytes. If you then remove this file, the directory "file" does *not* reduce
by 16 bytes....
Randy
-----------------------------
From: Edward Vielmetti <emv at mailrus.cc.umich.edu>
Subject: Re: cgrep (context-grep)
Date: 14 Jul 88 02:58:02 GMT
Sender: usenet at mailrus.cc.umich.edu
Followup-To: comp.unix.questions
Keywords: grep
To: unix-wizards at brl-sem.arpa
In article <2985 at cvl.umd.edu> arensb at lemuria.UUCP (Andrew Arensburger) writes:
>
> I'm thinking of writing a utility called cgrep, which works just
>like grep, but instead of writing out just the line on which the pattern
>was found, would write out a couple of lines surrounding the line in
>question.
when I needed to do this recently, this is what I cooked up on the
spur of the moment. It works, though it's by no means optimal.
cgrep:
#!/bin/sh
grep -v $1 $2 | diff -c - $2
all depends on whether your diff can handle standard input or now.
mine can (Apollo SR 10 beta).
You might note that there was a long discussion of 'gre', a new
project from at&t research to do grep right, and as I recall the
prevailing view from the "tools, pipes, filters" crowd was
that context doesn't belong in grep. The "features, features,
features" crowd thought otherwise.
I'd be interested in a cgrep if you wrote one.
--Ed
-----------------------------
From: Jeff Siegal <jbs at fenchurch.mit.edu>
Subject: Re: Input Line Editing
Date: 14 Jul 88 03:23:03 GMT
Sender: uucp at eddie.mit.edu
To: unix-wizards at brl-sem.arpa
In article <23839 at bu-cs.BU.EDU> bzs at bu-cs.BU.EDU (Barry Shein) writes:
>[...]if it's done as an intermediate process how
>does the process know when to step out of the way because a newly
>started job is doing its own style of input editing?
As Doug said, kernel support should be provided as necessary. In this
case, provide a way for the intermediate process to determine (or be
told) that the terminal (perhaps a pseudo-terminal) has been switched
out of cooked mode. As has already been pointed out, Emacs shell
buffers could use such a service to improve support for input editing.
Perhaps I missed this, but shouldn't the question be "How to provide
*better* input editing in Unix?" The kernel already provides limited
editing capability in cooked mode, yes?
Jeff Siegal
-----------------------------
From: Matt Costello <matt at ncr-sd.sandiego.ncr.com>
Subject: Re: Input Line Editing
Date: 14 Jul 88 03:22:17 GMT
To: unix-wizards at brl-sem.arpa
As regards the Input Line Editor, and where does it fit ...
Isn't this what STREAMS are for? Since a stream module has access
to the ioctls it should know when it is or is not wanted. It would
replace the standard line discipline available in cooked mode. The
ILE would then be available to all programs doing line mode input
from the user's terminal.
Which brings up the interesting question of where a streams module
would store 'instance' data since it is in the kernel address space.
The only thing I can see is that the streams module could grab a
free disk buffer or two to save the history.
--
Matt Costello <matt.costello at SanDiego.NCR.COM>
+1 619 485 2926 <matt.costello%SanDiego.NCR.COM at Relay.CS.NET>
{ucsd,att,pyramid,nosc.mil}!ncr-sd!matt
-----------------------------
From: "Alan S. Mazer" <alan at jane.jpl.nasa.gov>
Subject: Re: cgrep (context-grep)
Date: 14 Jul 88 02:22:15 GMT
Sender: uucp at elroy.jpl.nasa.gov
Keywords: grep
To: unix-wizards at brl-sem.arpa
In article <2985 at cvl.umd.edu>, arensb at cvl.umd.edu (Andrew Arensburger) writes:
> I'm thinking of writing a utility called cgrep, which works just like grep
You and everyone else. I've got one in C which is very similar to egrep, but
with one additional display-context option. You can select how many lines above
and below you want, and it uses egrep alone when it can. You're welcome to it.
Send mail. To people who got earlier versions, I've fixed a couple bugs since
then. If you want a new one, yell.
-- Alan ..!cit-vax!elroy!alan * "But seriously, what
elroy!alan at csvax.caltech.edu could go wrong?"
-----------------------------
From: Larry DeLuca <henrik at blblbl.uucp>
Subject: Re: where to do line editing?
Date: 14 Jul 88 01:26:24 GMT
To: unix-wizards at SEM.BRL.MIL
While it's not going to help the ile people much, it still seems the best
place for a line editor of some sort is still the tty driver (ioctl's
can be used to set characters or toggle between modes).
The most simple line editing commands (rubout, line delete, and co.) are
there already, and it is the only way to guarantee that they will be
uniformly supported.
The major complication, of course, is that this requires intelligence in
the tty driver about terminal escape sequences. ITS (Incompatible Time
Sharing, developed at MIT) has excellent support in this regard (the
tty driver knows how to do operations like clear the screen, and is also
aware of what's on the screen at any given time, so can repaint it after
a send, for example).
larry...
-----------------------------
From: Doug Alan <nessus at wonko.mit.edu>
Subject: Re: Input Line Editing
Date: 14 Jul 88 04:52:38 GMT
Sender: uucp at eddie.mit.edu
To: unix-wizards at SEM.BRL.MIL
>> [nessus at eddie.mit.edu:] There should also be a version of X that
>> runs in a limitted form, but supports the most basic features, on a
>> normal, dumb terminal, so you don't *have* to have a workstation to
>> use programs that don't need one.
> [guy at gorodish.Sun.COM (Guy Harris):] One of the "most basic
> features" of X11 is the ability to draw things such as lines, and
> curves, and so on and so forth, with pixel-level resolution.
Perhaps you (and perhaps the people who wrote X) consider this one of
the most basic features. I don't, however. I consider the most basic
features to be those that allow me to manage multiple text windows,
not all of which have to be visible, but all of which can contain
running programs creating output.
In any case, I don't want to get into an argument of what X is and
isn't. I just want to say how I think things should be: As I already
said (1) I think there should an input preprocessing facility that
provides input line editing for all programs that accept their input
as lines of text. (2) There should be an output processing facility
so that programs like "more" and "less" are not required. All the
capabilities of these programs should be in the output processing
facility. The output processing facility should also handle doing
anything fancy with the display (such as clearing the screen. moving
the cursor, etc). (3) The programs which implement these input and
output processing facilities should be selectable by the user. (4)
There should be a means of and protocol for communication between a
program and these input and output processing processes. (5) Some
kernal mods may be necessary to make this scheme simple and efficient.
For example, the input editor needs to be able to find out the current
working directory of the process to which it is sending the input. (6)
The X window system already does some of the above stuff, and the rest
could be added. (7) There should also be a standard set of programs
for normal 24x80 dumb terminals (let's call the programs "X--") that
do window management, and input and output processing of the sort
talked about above.
> If you're referring to the server for the X11 Window System, it
> should definitely *not* "have line editing added to it." The X11
> server is supposed to deliver extremely RAW key events to its
> clients, so that the clients aren't obliged to undo any
> "intelligence" that the server adds.
X already has some input editing, and it certainly doesn't deliver
"extremely RAW key events" to all of its clients. X allows me to cut
text that is on the screen, and paste it into my input. It allows me
to remap my keyboard. Is this "raw" key events? And indeed, these
input procressing capabilities should be expanded. Full line-editing
should be added. For example, at the bottom of every window that
accepts input, there could be a little one-line Emacs window (or your
choice of editor) that allows you to edit the current line (or recall
a previous line and edit it) and send it to the application when you
are finished with it.
In fact, you can already do something like this with X, but it's a
real pain. If you wanted to, you could type all your input into
Emacs, and use the cut and paste utilities to get all your keyboard
input from Emacs to the program you are using. This isn't worth the
bother, however.
> What if the client *isn't* using the keyboard as a "normal"
> terminal-style keyboard?
Then the application should be able to able to tell X, "hey, please
give me my input rarer", in a manner similar to that which allows a
normal Unix application to request input in "raw" or "cooked" mode.
> As for "every program should know about X", well, "cat" shouldn't
> know about X; it should only know about writing output to a file
> descriptor. The file descriptor goes to a pseudo-terminal (or moral
> equivalent); the output goes to an X11 client program, which
> displays it on the screen by sending requests to the X11 server.
> "cat" doesn't know about X; "xterm" does.
Perhaps I worded things a bit poorly. Certainly programs that don't
want to do anything fancy with the display, need not know anything
about X. I meant to say that any program that wants to do anything
fancy with the display (such as clear the screen, move the cursor,
etc) should not do it itself. It should know that there is a display
manager to do these sorts of things for it, and it should communicate
with the display manager using some prescribed protocol.
There should not be any programs such as "more" or "less". All the
functionality of these programs should be built into the display
manager.
> From: bzs at bu-cs.BU.EDU (Barry Shein)
> [...] The other question is, if [input line editing is] done as an
> intermediate process how does the process know when to step out of
> the way because a newly started job is doing its own style of input
> editing? (yes, I'm bracing myself for the answer...)
Well, recently posted to Unix-Wizards was "ile" -- "input line
editor". Ile seems to handle this by getting out of the way if any
process below it puts the terminal in cbreak or raw mode. This seems
to work most of the time, but not all of the time.
The right way to do this is to devise and standardize a convention and
means for communicating and coordinating this sort of thing between
processes.
|>oug /\lan
(or nessus at athena.mit.edu
nessus at mit-eddie.uucp)
P.S. While we're on the subject of changing Unix, the system call that
opens files should also be changed. It should be changed so that
wherever you can specify a file to run, you can also specify a
pipeline to run and use as a source of input or output. For example,
if a program prompts me like so:
Enter output file:
I should be able to enter something like:
Enter output file: ^(filter1 | justify -80 | tee \
^(filter2 | justify -40 > output-file2) \
> output-file1)
The output would get filtered through filter1, justified to 80
columns, and output to "output-file1". Another copy of the output
would get filtered through filter2, justified to 40 colums, and output
to "output-file2".
-----------------------------
End of UNIX-WIZARDS Digest
**************************
More information about the Comp.unix.wizards
mailing list