OPERATOR%LLL@LLL-MFE.arpa (10/06/86)
To: INFO-UNIX@BRL.ARPA Subject: Message of 5-Oct-86 06:34:34 Message undelivered after 1 day -- will try for another 2 days: DEVOTO@LLL.MFENET: Disk quota exceeded ------------ Received: from BRL.ARPA by LLL.MFENET; Sun 5 Oct 86 06:34:32-PDT Reply-to: INFO-UNIX@BRL.ARPA Subject: INFO-UNIX Digest V2#226 Date: Sun, 05 Oct 86 02:45:31 EST -------
OPERATOR%LLL@LLL-MFE.arpa (10/07/86)
To: INFO-UNIX@BRL.ARPA Subject: Message of 6-Oct-86 01:24:09 Message undelivered after 1 day -- will try for another 2 days: DEVOTO@LLL.MFENET: Disk quota exceeded ------------ Received: from BRL.ARPA by LLL.MFENET; Mon 6 Oct 86 01:24:08-PDT Reply-to: INFO-UNIX@BRL.ARPA Subject: INFO-UNIX Digest V2#227 Date: Mon, 06 Oct 86 02:45:23 EST -------
OPERATOR%LLL@LLL-MFE.arpa (10/07/86)
To: INFO-UNIX@BRL.ARPA Subject: Message of 5-Oct-86 06:34:34 Message undelivered after 2 days -- will try for another 1 day: DEVOTO@LLL.MFENET: Disk quota exceeded ------------ Received: from BRL.ARPA by LLL.MFENET; Sun 5 Oct 86 06:34:32-PDT Reply-to: INFO-UNIX@BRL.ARPA Subject: INFO-UNIX Digest V2#226 Date: Sun, 05 Oct 86 02:45:31 EST -------
OPERATOR%LLL@LLL-MFE.arpa (10/08/86)
To: INFO-UNIX@BRL.ARPA Subject: Message of 6-Oct-86 01:24:09 Message undelivered after 2 days -- will try for another 1 day: DEVOTO@LLL.MFENET: Disk quota exceeded ------------ Received: from BRL.ARPA by LLL.MFENET; Mon 6 Oct 86 01:24:08-PDT Reply-to: INFO-UNIX@BRL.ARPA Subject: INFO-UNIX Digest V2#227 Date: Mon, 06 Oct 86 02:45:23 EST -------
OPERATOR%LLL@LLL-MFE.arpa (10/08/86)
To: INFO-UNIX@BRL.ARPA Subject: Message of 7-Oct-86 02:37:44 Message undelivered after 1 day -- will try for another 2 days: DEVOTO@LLL.MFENET: Disk quota exceeded ------------ Received: from BRL.ARPA by LLL.MFENET; Tue 7 Oct 86 02:37:37-PDT Reply-to: INFO-UNIX@BRL.ARPA Subject: INFO-UNIX Digest V2#228 Date: Tue, 07 Oct 86 02:46:03 EST -------
OPERATOR%LLL@LLL-MFE.arpa (10/08/86)
To: INFO-UNIX@BRL.ARPA
Subject: Message of 5-Oct-86 06:34:34
Message undeliverable and dequeued after 3 days:
DEVOTO@LLL.MFENET: Disk quota exceeded
------------
Received: from BRL.ARPA by LLL.MFENET; Sun 5 Oct 86 06:34:32-PDT
Reply-to: INFO-UNIX@BRL.ARPA
Subject: INFO-UNIX Digest V2#226
Date: Sun, 05 Oct 86 02:45:31 EST
Return-Path: <info-unix-request@BRL-SEM.arpa>
Received: from BRL-SEM.ARPA by LLL-MFE.ARPA; Sun, 5 Oct 86 06:32 PDT
Received: from BRL-SEM.ARPA by SEM.BRL.ARPA id ab03039; 5 Oct 86 2:58 EDT
Received: from BRL-SEM.ARPA by SEM.BRL.ARPA id aa03026; 5 Oct 86 2:45 EDT
Date: Sun, 05 Oct 86 02:45:31 EST
From: The Moderator (Mike Muuss) <Info-Unix-Request@BRL.ARPA>
To: INFO-UNIX@BRL.ARPA
Reply-To: INFO-UNIX@BRL.ARPA
Subject: INFO-UNIX Digest V2#226
Message-ID: <8610050245.aa03026@SEM.BRL.ARPA>
INFO-UNIX Digest Sun, 05 Oct 1986 V2#226
Today's Topics:
Dissimilar Program Interaction?
VI features
Re: Where can I get "build"?
Things that could be done to improve vi
Re: Modelessness (Was porting UNIX applications to the mac)
Re: catching FPEs?
-----------------------------------------------------------------
From: kadie@b.cs.uiuc.edu
Subject: Dissimilar Program Interaction?
Date: 30 Sep 86 23:58:00 GMT
Nf-ID: #N:uiucdcsb:19300054:000:868
Nf-From: uiucdcsb.cs.uiuc.edu!kadie Sep 30 18:58:00 1986
To: info-unix@brl-sem.arpa
I need to allow a number of very dissimilar programs to
interact. Each of the programs reads from standard input
and writes to standard output.
I imagine that I want Unix pipes connecting each of the
sub-programs to an executive program.
Looking through the UNIX library I found a function that
does almost what I want, namely popen. As in:
FILE *pstrm;
pstrm = popen("cat >response","w")
This will start cat running such that the executive can
make stream writes (fprint) to it. The problem is
that I want to both fscan and fprint with each subprocesses.
An alternative function is the pipe command. It allows
read and write. Unfortunately I don't know how to
connect the pipe(s) to standard input and standard output
of the sub-program.
Also this does not permit fscan and fprint.
Any advice or leads will be desperately appreciated.
Carl Kadie
-----------------------------
From: BALDWIN <mike%whuxl.uucp@BRL.ARPA>
Subject: VI features
Date: 1 Oct 86 20:51:20 GMT
To: info-unix@brl-sem.arpa
When I found out that vi 3.9 understood function keys and had
showmode (puts an I in the lower right corner when in insert
mode, R in Replace, r in replace), I thought "neato!" but after
using them for 5 minutes I got quite disgusted at the number of
bugs in the implementation:
The mode indicator goes off if you auto-word-wrap on the last
line of the screen.
The mode indicator goes off if you use any function keys while
in insert mode.
You are kicked out of insert mode if you get a beep from a
function key; e.g., if you use the arrows and hit the end
of a line.
If you press a function key while in Replace mode, you are
put back into Input mode instead of Replace (of course the
indicator has disappeared because of bug #2).
Function keys are implemented from insert mode by simulating
an ESC, doing the function, then simulating an "i" command.
This means if you are in a "cw" command, the line gets scrunched
when you press an arrow key, for instance. Not exactly a bug,
but it is surprising. This causes very undesirable behaviour
for some function keys, for example DELCHAR. When you press
DELCHAR in command mode, it executes the x command and deletes
the character under the cursor. Fair enough. Now say you are
in input mode. When you hit DELCHAR, an ESC is simulated, so
the cursor moves back one. Then DELCHAR (x) is done, deleting
the current char, and you are put back in input mode (i). This
has the net result of deleting the character IN FRONT OF the
cursor. Now try to explain this to a novice:
The DELCHAR key deletes the current character in command
mode, but it deletes the previous one in input mode.
Sounds stupid, doesn't it?
The main problem with VI from a screen editor point of view is that it
is really a line-oriented screen editor:
Forward and back word (b & w) go around lines, but forward and
back character don't. Also, forward word gets stuck at the end
of a line if it ends with a space.
Vi always wants the cursor to be on top of a character, instead
of between characters, so you can't have a 0-length buffer, and
empty lines look like lines with one space (the only easy way to tell
them apart is to do an "x" on the line and see if it beeps).
The newline character is a magic cookie. I can't point the cursor
to it, and I can't treat it like a normal character. Therefore,
because you can't "x" it, vi has another random command: Join.
This is the crux of the problem.
You can't backspace around newlines in input mode.
If you hit your line kill character in input mode, that line is
gone forever. It's sitting there in front of you, but you have
to type it in again.
In auto-indent mode, you have to type ^D to undent. Why doesn't
backspace work?
The other problem is that it is NOT a WYSIWYG editor:
You type any change command (c,C,etc) and you get this
funny $ at the end of the changed region and the $ and the
text you changed aren't really there. *Many* times I've had
novices use the C command and hit spaces to the end of the line
because they wanted to get rid of text that they didn't know
was already "gone".
This really makes it difficult to tell a new user what is
going on. You'd like to say "what's on the screen is what's
in the buffer" but it just isn't true.
Also random inconsistencies that make it very difficult to make
blanket statements:
The ]] command goes to the next line starting with {, but if
you use "d]]" it deletes to the next line starting with }.
I thought that the "d" command took a following motion command
and deleted from the current position to where the motion would
take me, but apparently not always.
I tried teaching VI to computer novices, but gave up because of the
non-WYSIWYG property and the constant confusion between input and
command mode. (This was 3.7 vi on BSD, so there was no showmode.
Even if there were, it would have been too brain-damaged to use.)
I was constantly trying to explain things like the DELCHAR botch
or the $ stuff which makes absolutely no sense to the average user.
Then I got smart and typed up a short command list of the 30 most
common EMACS commands arranged by function, and the pleas for help
dropped off dramatically.
--
Michael Baldwin
(not the opinions of) AT&T Bell Laboratories
{at&t}!whuxl!mike
-----------------------------
From: David Korn <dgk%ulysses.uucp@BRL.ARPA>
Subject: Re: Where can I get "build"?
Date: 2 Oct 86 03:48:28 GMT
To: info-unix@brl-sem.arpa
>
> I just finished reading a paper about "build", a superset of make developed
> at AT&T. I'm hooked--it does everything we've been looking for. We have
> multiple people working on the same code and build will keep us from destroying
> each other. There's only one problem--where do you get it? Does AT&T sell
> it? How much does it cost?
>
> If you're interested in reading the paper, it's as follows:
>
> Build--A Software Construction Tool
> V.B. Erickson and J.F. Pellegrin
> AT&T Bell Labs Technical Journal
> Vol. 63, No 6, July-Aug. 1984
>
> -----------------
>
> Patrick W. Peters
> Texas Instruments
> Process Automation Center
> P.O. Box 655012, M/S 3635
> Dallas, TX 75243
>
> UUCP: {uiucdcs!convex!smu, {rice, sun!texsun}!ti-csl}!tifsie!pat
> Voice: (214) 995-2786
You should read the paper in the proceedings of the Portland Usenix about
4th generation make. This new version of make is rapidly replacing build
as the 'make' utility at AT&T. Makefiles or typically about one fifth
the size and it runs much faster than build.
It supports a multi-directory, multi-version model of the source code as
build does, but it does it without copying files. This is especially
important if you find out what happens if the machine goes down in the
middle of a build and you have to clean up.
The best news is that 4th generation make is available through the
Unix System Toolchest which is an electronic software distribution
system. You can login to the Toolchest by dialing (201) 582-6900
and logging in as guest.
David Korn
ulysses!dgk
-----------------------------
From: dave%murphy.uucp@BRL.ARPA
Subject: Things that could be done to improve vi
Date: 30 Sep 86 13:52:14 GMT
To: info-unix@brl-sem.arpa
My two cents' worth on the editor wars: although I'm not to get into the
"my editor is better than your editor" thing (sounds like net.sport.baseball),
I would like to see a couple of things in vi that would make it a little less
frustrating to use in certain applications. They are:
1. An on-screen mode indicator, so that you know whether you're in a text
entry mode or a command mode. (Also, an indicator that would show whether
or not you've made any changes to the current file would be nice.)
2. A software caps-lock function that would shift all alpha keys typed in
a text-entry mode to upper case. What do I want this for? We have a number
of Fortran (no flames) programs that were ported from another operating
system which are written in all upper case. To maintain the style and
readability of these programs, we have a rule that all new code put into them
must be done in upper case (except comments). Well, the temptation when
working on these is to just hit the caps-lock button and go to work; the
problem is that if you go back to command mode and forget to take off the
caps lock, your commands will be in upper case and will do something you
didn't expect.
3. A way to change the text-entry exit key to something other than <ESC>.
The reason is that if you're working on a VT100-type terminal, and you
accidentally go for an arrow key while you're in a text entry mode, the
<ESC> that is transmitted at the beginning of the key's sequence will
throw you back to command mode, and the remaining characters will do
something rude to your buffer. If the text-entry termination key isn't
<ESC>, all that happens is that you get three garbage characters which
you can easily backspace over.
4. A "help" function that would present an on-screen quick-and-dirty cheat
sheet would be nice. (Actually, this would be more of a reminder function
that you could use when you can't remember the key for a certain command,
not a substitute for the manual section.)
5. When the "noeb" (no error bells) option is set, THE DAMN THING SHOULD
*NOT* SEND BELLS -- EVER!
---
It's been said by many a wise philosopher that when you die and your soul
goes to its final resting place, it has to make a connection in Atlanta.
Dave Cornutt, Gould Computer Systems, Ft. Lauderdale, FL
UUCP: ...{sun,pur-ee,brl-bmd}!gould!dcornutt
or ...!ucf-cs!novavax!houligan!dcornutt
ARPA: wait a minute, I've almost got it...
"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."
-----------------------------
From: Barry Margolin <barmar@eddie.mit.edu>
Subject: Re: Modelessness (Was porting UNIX applications to the mac)
Date: 2 Oct 86 02:56:37 GMT
To: info-unix@brl-sem.arpa
In article <2637@cbosgd.ATT.COM> mark@cbosgd.ATT.COM (Mark Horton) writes:
>In article <585@zeus.UUCP> bobr@zeus.UUCP (Robert Reed) writes:
>> A useful definition of mode is a state of a user interface that affects
>> the interpretation of subsequent inputs without obvious indication.
>>
>>The operant words here are "WITHOUT OBVIOUS INDICATION."
...
>>As a novice user of vi, I was constantly surprised by trying to
>>enter text, only to find that I was in command mode (with no obvious
>>indication). That is the point.
>
>Sorry, Bob, I disagree. Your version of vi (3.7) doesn't show you when
>you're in input mode, but mine (3.10) does; so does the MS DOS PC/VI
>clone. (It says "INPUT MODE" right there on the bottom line, or "I"
>if you have terse set. There are similar messages for r and R modes.)
...
>In spite of this, I still consider vi a moded editor, and I think most
>others do too. As an extreme example, ex command mode is certainly a
>mode, with a very obvious visual indication (the : prompt and cursor
>at the bottom of the screen.)
>
>There's nothing wrong with being moded,
I think that we need to decide how "obvious" the indications must be
before one is willing to call something "modeless". I don't consider a
word or two somewhere else on the screen, or a change in shape of the
cursor (as is common in many PC applications) obvious enough. However,
moving the cursor out of the window, as is done for Emacs ESC-X commands
or Macintosh dialogs, is about as obvious as you can get without
grabbing the user by the collar and screaming "What extended command do
you want?" in his ear.
Emacs and MacWrite, however, are only modeless to a slightly greater
extent than vi. Emacs has major (C, Lisp, Fundamental) and minor (Auto
Fill, Overwrite, Macro Learn) modes. MacWrite has modes that specify
the justification, font, and style of the text to be typed in. I think
that the difference between these and vi is the extent to which use of
the editor depends on the modes; a novice Emacs user might hardly ever
change modes, but a vi can't be used without going between insert,
overwrite, and edit modes relatively frequently.
--
Barry Margolin
ARPA: barmar@MIT-Multics
UUCP: ..!genrad!mit-eddie!barmar
-----------------------------
From: Rick Perry <perry%vu-vlsi.uucp@BRL.ARPA>
Subject: Re: catching FPEs?
Date: 2 Oct 86 03:31:14 GMT
To: info-unix@brl-sem.arpa
In article <371@vu-vlsi.UUCP> colin@vu-vlsi.UUCP (Colin Kelley) writes:
>I'm using 4.2bsd on a Pyramid...
>...
>Is there some way to trap FPEs and then indicate that you want to resume
>execution _after_ the code which caused the FPE?
You didn't mention that your program is written in C, but I guess that's
the default in the Real World. If it was Fartran, you could simply do:
call trpfpe( inmax(), dflmax() )
thereby specifying that Floating Point Execptions are to be replaced
by dflmax() (largest double float on the machine) for up to inmax()
(largest integer on the machine) occurances. These things are available
on Pyramid from f77, don't know about other machines, but perhaps there
is an easy way to call that from C on Pyramid ?
When you do that, the FPE's are trapped and fixed, and msg like:
on_fpe: floating point exception (or overflow or something...)
or something like that is printed on stdout or stderr, not sure which...
...Rick ..somewhere!here!f77!vu-vlsi!perry
-----------------------------
End of INFO-UNIX Digest
***********************
-------OPERATOR%LLL@LLL-MFE.arpa (10/09/86)
To: INFO-UNIX@BRL.ARPA
Subject: Message of 6-Oct-86 01:24:09
Message undeliverable and dequeued after 3 days:
DEVOTO@LLL.MFENET: Disk quota exceeded
------------
Received: from BRL.ARPA by LLL.MFENET; Mon 6 Oct 86 01:24:08-PDT
Reply-to: INFO-UNIX@BRL.ARPA
Subject: INFO-UNIX Digest V2#227
Date: Mon, 06 Oct 86 02:45:23 EST
Return-Path: <info-unix-request@BRL-SEM.arpa>
Received: from BRL-SEM.ARPA by LLL-MFE.ARPA; Mon, 6 Oct 86 01:22 PDT
Received: from BRL-SEM.ARPA by SEM.BRL.ARPA id aa06901; 6 Oct 86 3:01 EDT
Received: from BRL-SEM.ARPA by SEM.BRL.ARPA id ab06849; 6 Oct 86 2:45 EDT
Date: Mon, 06 Oct 86 02:45:23 EST
From: The Moderator (Mike Muuss) <Info-Unix-Request@BRL.ARPA>
To: INFO-UNIX@BRL.ARPA
Reply-To: INFO-UNIX@BRL.ARPA
Subject: INFO-UNIX Digest V2#227
Message-ID: <8610060245.ab06849@SEM.BRL.ARPA>
INFO-UNIX Digest Mon, 06 Oct 1986 V2#227
Today's Topics:
Re: Modelessness (Was porting UNIX applications to the mac)
-----------------------------------------------------------------
From: Robert Reed <bobr%zeus.uucp@BRL.ARPA>
Subject: Re: Modelessness (Was porting UNIX applications to the mac)
Date: 1 Oct 86 19:19:41 GMT
Posted: Wed Oct 1 15:19:41 1986
To: info-unix@brl-sem.arpa
In article <2637@cbosgd.ATT.COM> mark@cbosgd.ATT.COM (Mark Horton) writes:
>
>Sorry, Bob, I disagree. Your version of vi (3.7) doesn't show you when
>you're in input mode, but mine (3.10) does; so does the MS DOS PC/VI
>clone. (It says "INPUT MODE" right there on the bottom line,...
This change sounds like a definite improvement and one that I wouldn't
criticize without having a chance to see it, but an immediate concern of
mine would be how visible this indicator is for someone whose focus of
attention is the cursor, not the bottom of the screen. I still might not
consider this indication as "obvious."
>There's nothing wrong with being moded, it's just a personal preference.
I agree that modes are useful and far be it from me to presume that either
vi or emacs be considered modeless. My argument was not for the elimination
of modes, but for the elimination of modes which demonstrate the two
following features:
o Their presence is not obvious to the user (whatever this means in
terms of visual or mechanical feedback).
o The mechanism for exiting them is not obvious.
There are features of both vi and emacs that arguably fall within these
dictates. The criterion for "obviousness" is necessarily vague, because
level of expertise will affect the user's perceptions of natural behavior.
Knowing to hit ESC in vi is a learned behavior, just as is knowing to hit ^G
in emacs to abort multi-keystroke commands. Neither is particularly obvious
if you don't know about them in advance.
>Mice and other pointing devices are handy for lots of things, but with
>only two hands, you can't keep one hand on the mouse all the time.
>
>...for a text editor, you can't reasonably input new text with a mouse,
>and there's the problem.
Agreed. Despite the attractiveness of the "cut and paste" style text
editing paradigm, the actual mechanics of using such a system for text
editing are cumbersome. That is not the same as saying that keyboard driven
editing and cut-and-paste editing cannot be used in concert. Cut-and-paste
grafted onto emacs would be a definite wart, but a useful one.
Robert Reed, Tektronix CAE Systems Division, bobr@zeus.TEK
-----------------------------
End of INFO-UNIX Digest
***********************
-------OPERATOR%LLL@LLL-MFE.arpa (10/09/86)
To: INFO-UNIX@BRL.ARPA Subject: Message of 8-Oct-86 01:30:58 Message undelivered after 1 day -- will try for another 2 days: DEVOTO@LLL.MFENET: Disk quota exceeded ------------ Received: from BRL.ARPA by LLL.MFENET; Wed 8 Oct 86 01:30:52-PDT Reply-to: INFO-UNIX@BRL.ARPA Subject: INFO-UNIX Digest V2#229 Date: Wed, 08 Oct 86 02:45:45 EST -------
OPERATOR%LLL@LLL-MFE.arpa (10/09/86)
To: INFO-UNIX@BRL.ARPA Subject: Message of 7-Oct-86 02:37:44 Message undelivered after 2 days -- will try for another 1 day: DEVOTO@LLL.MFENET: Disk quota exceeded ------------ Received: from BRL.ARPA by LLL.MFENET; Tue 7 Oct 86 02:37:37-PDT Reply-to: INFO-UNIX@BRL.ARPA Subject: INFO-UNIX Digest V2#228 Date: Tue, 07 Oct 86 02:46:03 EST -------
gaspar@ALMSA-1.arpa (Al Gaspar) (10/09/86)
Can anything be done about these messages? I've deleted about a dozen of these, but they keep coming back. ----- Forwarded message # 1: Received: from almsa-1.arpa by ALMSA-1.ARPA id a019672; 9 Oct 86 7:05 CDT Received: from brl-sem.arpa by ALMSA-1.ARPA id a019988; 9 Oct 86 6:39 CDT Received: from BRL-SEM.ARPA by SEM.BRL.ARPA id aa06791; 9 Oct 86 6:23 EDT Received: from BRL-AOS.ARPA by SEM.BRL.ARPA id aa06748; 9 Oct 86 6:17 EDT Received: from lll-mfe.arpa by AOS.BRL.ARPA id a027243; 9 Oct 86 6:12 EDT Date: Thu, 9 Oct 86 10:09 GMT From: OPERATOR%LLL@LLL-MFE.ARPA Subject: The Mailer Daemon <Mailer@LLL.MFENET> To: INFO-UNIX@BRL.ARPA Message-ID: <8610090617.aa06748@SEM.BRL.ARPA> To: INFO-UNIX@BRL.ARPA Subject: Message of 7-Oct-86 02:37:44 Message undelivered after 2 days -- will try for another 1 day: DEVOTO@LLL.MFENET: Disk quota exceeded ------------ Received: from BRL.ARPA by LLL.MFENET; Tue 7 Oct 86 02:37:37-PDT Reply-to: INFO-UNIX@BRL.ARPA Subject: INFO-UNIX Digest V2#228 Date: Tue, 07 Oct 86 02:46:03 EST ------- ----- End of forwarded messages Al Gaspar <gaspar@almsa-1.arpa> USAMC ALMSA, ATTN: AMXAL-OW, Box 1578, St. Louis, MO 63188-1578 COMMERCIAL: (314) 263-5118 AUTOVON: 693-5118 seismo!gaspar@almsa-1.arpa