Received: from PREP.AI.MIT.EDU by MC.LCS.MIT.EDU via Chaosnet; 25 DEC 85  00:44:36 EST
Received: from CSNET-RELAY.ARPA by prep; Wed, 25 Dec 85 00:41:14 est
Received: from bostonu by csnet-relay.csnet id ab03196; 23 Dec 85 19:25 EST
Received: by bu-cs.ARPA (4.12/4.7)
	id AA24284; Mon, 23 Dec 85 16:17:03 est
Date: Mon, 23 Dec 85 16:17:03 est
From: Michael Forte <ccmf%bostonu.csnet@CSNET-RELAY.ARPA>
To: info-gnu@mit-prep.csnet
Subject: porting gnuemacs (v16 or v17) to Celerity Computing C1200

Anyone out there try to port gnuemacs to a Celerity Computing C1200 machine?
It runs the Celerity version of Bsd 4.2, which is not very different from
Bsd 4.2 on a Vax.  The C compiler is much more strict though, so addresses
must be valid or segmentation violations will occur, which would not necessarily
happen on a Vax.
We use the machine mainly for graphics numerical computations, for which it
is excellent and extremely fast. I would like to put gnuemacs on it, since it's
the best editor we have access to.
Also appreciated would be hints on debugging gnuemacs without the modified
debugger provided by RMS.


Received: from MIT-JIMI by MIT-MC.ARPA via Chaosnet; 15 DEC 85  03:39:33 EST
Date: Sun, 15 Dec 85 03:37 EST
From: David Vinayak Wallace <Gumby@MIT-MC.ARPA>
Subject: McKusick quote
To: davidson@SDCSVAX.ARPA
cc: info-gnu@MIT-MC.ARPA
In-Reply-To: <8512112110.AA21057@vis.uucp>
Message-ID: <851215033724.5.GUMBY@JIMI.AI.MIT.EDU>

    Date: 11 Dec 85 13:10:30 PST (Wed)
    From: vis!greg@SDCSVAX.ARPA

    ...They think that a new system
    will be developed that consists of a small kernel-kernel providing only
    the lowest level of message passing, hardware scheduling, and virtual
    memory management.  The current UNIX kernel will be broken into several
    server processes on top of the kernel-kernel.  Sample services from
    existing UNIX systems include a file system server, a TCP/IP network
    server, and a terminal line server....

Amazing as it may seem, such a system, was developed during the 1960s.
Has this all come full circle?

Isn't this similar to arpa's new OS project?

Received: from MIT-PREP.ARPA by MIT-MC.ARPA via Chaosnet; 13 DEC 85  20:25:20 EST
Received: from sdcsvax.ARPA (1003680) by prep; Fri, 13 Dec 85 20:19:56 est
Received: by sdcsvax.ARPA (5.31/4.41)
	id AA28741; Wed, 11 Dec 85 17:15:40 PST hops=0
From: vis!greg@SDCSVAX.ARPA
Received: by vis.uucp (2.0/3.14)
	id AA21057; Wed, 11 Dec 85 13:10:41 pst
Message-Id: <8512112110.AA21057@vis.uucp>
To: "Richard M. Stallman" <RMS@mit-mc.arpa>
Cc: info-gnu@mit-prep.arpa
Subject: Re: termcap replacement + McKusick quote
In-Reply-To: Your message of Sun,  3 Nov 85 19:44:04 EST.
	     <[MIT-MC.ARPA].703572.851103.RMS>
Date: 11 Dec 85 13:10:30 PST (Wed)

Your new termcap sounds like a nice improvement over the old one, but
have you looked at terminfo?  Pavel Curtis did a public domain
implementation of both termcap and terminfo and distributed them over
net.sources.  As terminfo is replacing termcap in the UNIX community,
it would seem that GNU ought to use terminfo.  Besides, terminfo is
much nicer.  If you need a copy of Pavel's code, I can send you one.

I recently read (in the October ``UNIX Review'') an interesting article
by Kirk McKusick, and wanted to share a bit of it with the group:

``The challenge facing UNIX researchers today is the need to add
functionality capable of supporting environments while they produce
kernel modifications that will allow UNIX to run in a multiprocessor
environment.  Since system complexity increases much faster than the
size of its code, the current structure requiring a monolithic kernel
may become untenable.  However, growing familiarity with the UNIX
interface argues strongly in favor of maintaining it.

``Some researchers now believe that the revolution will come from below
without end users being any the wiser.  They think that a new system
will be developed that consists of a small kernel-kernel providing only
the lowest level of message passing, hardware scheduling, and virtual
memory management.  The current UNIX kernel will be broken into several
server processes on top of the kernel-kernel.  Sample services from
existing UNIX systems include a file system server, a TCP/IP network
server, and a terminal line server.  New services might include an Ada
development server or a document preparation environment server.  Users
familiar with existing UNIX systems could continue to run on top of the
UNIX file system server, while users wishing to work within an Ada
environment could work with an object-based file system through an
object-oriented Ada database server.  Synchronization between the
servers could be offered by the message interface provided by the
kernel-kernel.  By restructuring synchronization through messages
rather than by using a global-shared memory, servers could be decoupled
from the particular processor they run on.  The servers would be able
to interact equally well whether they were on the same processor, two
processors running together, or on two processors separated by miles of
network cable.''


_Greg Davidson			Virtual Infinity Systems, San Diego

greg@vis.uucp			ucbvax--| telesoft--|
davidson@sdcsvax.uucp		decvax--+--sdcsvax--+--vis
davidson@ucsd.arpa		 ihnp4--| celerity--|

Received: from harvard.HARVARD.EDU by MIT-MC.ARPA 22 Nov 85 01:14:32 EST
From: packard!allegra!utcsri!ubc-vision!mdivax1!haft%topaz.UUCP@harvard.HARVARD.EDU
Received: by topaz.rutgers.edu; Fri, 22 Nov 85 00:41:09 est
Date: Wed, 20 Nov 85 11:08:55 pst
Subject: GNU tar 
Message-Id: <8511220540.AA02169@py/garage/packard.DK>
Received: from py/garage/packard.DK by ihnp1.ATT.UUCP id AA03766; 21 Nov 85 23:40:15 CST (Thu)
Received: by utcsri.UUCP (4.24/5.1.UofT)
	id AA01309; Thu, 21 Nov 85 08:28:52 est
Received: by ubc-vision.UUCP id AA25999; Thu, 21 Nov 85 04:18:46 pst
Received: by mdivax1.UUCP (4.12/4.7) id AA07827; Wed, 20 Nov 85 11:08:55 pst
Received: from allegra.UUCP by py/garage/packard.DK; 8511220540
Received: from ihnp1.UUCP by py/garage/packard.DK; 8511220540
To: packard!harvard!MIT-MC.ARPA!INFO-GNU

Greetings,

I have a physically mangled tar tape which I'm trying to recover, and 
I would appreciate having a copy of the source to GNU tar utility. It
will give me a head start.

Please send the replies using E-mail. My net address is:

ubc-vision!mdivax1!haft

Thanks.

Received: from SRI-NIC.ARPA by MIT-MC.ARPA 18 Nov 85 17:01:12 EST
Date: Mon 18 Nov 85 13:26:15-PST
From: Ian Macky <Ian@SRI-NIC.ARPA>
Subject: libm
To: info-gnu@MIT-MC.ARPA
Message-ID: <12160307884.29.IAN@SRI-NIC.ARPA>

is there a public-domain math library (libm) around that i can swipe?

failing that, i am willing to translate from fortran or anything else
that's legible without massive effort...

failing that, can someone loan me a CRC book of math tables'n'trivia?

--ian@nic
-------

Received: from MIT-PREP.ARPA by MIT-MC.ARPA via Chaosnet; 11 NOV 85  16:27:51 EST
Received: by prep (4.12/4.7)
	id AA19502; Mon, 11 Nov 85 16:25:55 est
Date: Mon, 11 Nov 85 16:25:55 est
From: rms@prep (Richard M. Stallman)
To: info-gnu@prep
Subject: [rlk@ATHENA.MIT.EDU: [simsong: GNU Echo, Release 1]]

Date: Mon, 11 Nov 85 14:55:37 est
From: rlk@ATHENA.MIT.EDU
To: watchmakers, rms@prep, kin@seismo
Subject: [simsong: GNU Echo, Release 1]

Date: 10 Nov 1985 10:28:22-EST
From: simsong@MEDIA-LAB.MIT.EDU@MIT-CCC
Date: Sun, 10 Nov 85 10:29:24 est
From: Simson Garfinkel <simsong@MEDIA-LAB.MIT.EDU>
To: info-cobol@mit-ccc

Relay-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site mit-amt.MIT.EDU
Posting-Version: Notesfiles $Revision: 1.6.2.14 $; site umn-cs.UUCP
Path: mit-amt!mit-eddie!think!harvard!seismo!gatech!akgua!whuxlm!whuxl!houxm!ihnp4!stolaf!umn-cs!herndon
From: herndon@umn-cs.UUCP
Newsgroups: net.sources
Subject: GNU Echo, Release 1
Message-ID: <1600001@umn-cs.UUCP>
Date: 28 Oct 85 18:23:00 GMT
Date-Received: 10 Nov 85 05:29:10 GMT
Lines: 203
Nf-ID: #N:umn-cs:1600001:000:3177
Nf-From: umn-cs!herndon    Oct 28 12:23:00 1985


/* Written 12:22 pm  Oct 28, 1985 by umn-cs!herndon in umn-cs:net.jokes */
/* ---------- "GNU Echo, Release 1" ---------- */




GNUecho(1)	    UNIX Programmer's Manual	       GNUecho(1)



NAME
     echo - echo arguments

SYNOPSIS
     echo [ options ] ...

DESCRIPTION
     _E_c_h_o writes its arguments separated by blanks and terminated
     by	a newline on the standard output.  Options to filter and
     redirect the output are as	follows:

     -2	  generate rhyming couplets from keywords

     -3	  generate Haiku verse from keywords

     -5	  generate limerick from keywords

     -a	  convert ASCII	to ASCII

     -A	  disambiguate sentence	structure

     -b	  generate bureaucratese equivalent (see -x)

     -B	  issue	equivalent C code with bugs fixed

     -c	  simplify/calculate arithmetic	expression(s)

     -C	  remove copyright notice(s)

     -d	  define new echo switch map

     -D	  delete all ownership information from	system files

     -e	  evaluate lisp	expression(s)

     -E	  convert ASCII	to Navajo

     -f	  read input from file

     -F	  transliterate	to french

     -g	  generate pseudo-revolutionary	marxist	catch-phrases

     -G	  prepend GNU manifesto

     -h	  halt system (reboot suppressed on Suns, Apollos, and
	  VAXen, not supported on NOS-2)

     -i	  emulate IBM OS/VU (recursive universes not supported)

     -I	  emulate IBM VTOS 3.7.6 (chronosynclastic infundibulae
	  supported with restrictions documented in IBM	VTOS



Printed	10/28/85	 18 January 1983			1






GNUecho(1)	    UNIX Programmer's Manual	       GNUecho(1)



	  Reference Manual rev 3.2.6)

     -J	  generate junk	mail

     -j	  justify text (see -b option)

     -k	  output "echo"	software tools

     -K	  delete privileged accounts

     -l	  generate legalese equivalent

     -L	  load echo modules

     -M	  generate mail

     -N	  send output to all reachable networks	(usable	with -J,
	  -K, -h options)

     -n	  do not add newline to	the output

     -o	  generate obscene text

     -O	  clean	up dirty language

     -p	  decrypt and print /etc/passwd

     -P	  port echo to all reachable networks

     -P1  oolcay itay

     -q	  query	standard input for arguments

     -r	  read alternate ".echo" file on start up

     -R	  change root password to "RMS"

     -s	  suspend operating system during output (Sun and VAX BSD
	  4.2 only)

     -S	  translate to swahili

     -T	  emulate TCP/IP handler

     -t	  issue	troff output

     -u	  issue	unix philosophy	essay

     -v	  generate reverberating echo

     -V	  print	debugging information




Printed	10/28/85	 18 January 1983			2






GNUecho(1)	    UNIX Programmer's Manual	       GNUecho(1)



     -x	  decrypt DES format messages (NSA secret algorithm CX
	  3.8, not distributed outside continental US)

     _E_c_h_o is useful for	producing diagnostics in shell programs
     and for writing constant data on pipes.  To send diagnostics
     to	the standard error file, do `echo ... 1>&2'.

AUTHOR
     Richard M.	Stallman














































Printed	10/28/85	 18 January 1983			3



/* End of text from umn-cs:net.jokes */



Received: from MIT-PREP.ARPA by MIT-MC.ARPA via Chaosnet; 3 NOV 85  20:08:04 EST
Received: from MIT-MC.ARPA by MIT-PREP (4.12/4.8) with CHAOS 
	id AA00842; Sun, 3 Nov 85 19:44:05 est
Date: Sun,  3 Nov 85 19:44:04 EST
From: "Richard M. Stallman" <RMS@MIT-MC.ARPA>
Subject: Re: TRIX arrives
To: vis!greg@SDCSVAX.ARPA, info-gnu@MIT-PREP.ARPA
Message-Id: <[MIT-MC.ARPA].703572.851103.RMS>

Sieber says that it was the first version of TRIX, that used
message passing, that was too slow, and the second version,
which uses remote procedure call, isn't slow.

I'm still only a little way into reading the code, since I've
been mostly working on Emacs and its documentation.

This weekend I wrote a replacement for termcap that also provides for
strings with multiple parameters, and optionally for dynamic
allocation of all storage, avoiding danger of overflowing buffers.

Received: from MIT-PREP.ARPA by MIT-MC.ARPA via Chaosnet; 1 NOV 85  18:21:13 EST
Received: from sdcsvax.ARPA (sdcsvax.arpa.ARPA) by MIT-PREP.ARPA (4.12/4.8) 
	id AA13977; Fri, 1 Nov 85 18:18:18 est
Received: by sdcsvax.ARPA (5.31/4.41)
	id AA29744; Fri, 1 Nov 85 15:19:48 PST hops=0
From: vis!greg@sdcsvax.arpa
Received: by vis.uucp (2.0/3.14)
	id AA27679; Fri, 1 Nov 85 13:57:05 pst
Message-Id: <8511012157.AA27679@vis.uucp>
To: info-gnu@mit-prep.arpa
Cc: vis!greg@SDCSVAX.ARPA
Subject: Re: TRIX arrives
Date: 01 Nov 85 13:57:00 PST (Fri)

Boy, mention of TRIX really takes me back.  It seems like its been
about ten years since I first read about it, and I can't find my TRIX
documents any more.  I felt at the time that TRIX was a very elegant
generalization of UNIX, and well worth implementing.

Later I heard that the project had died due to the terrible performance
of the implementation.  I've spoken with a few ex-TRIX project members
who have confirmed this.  I never saw in the design anything forcing
such poor performance, and I hope (but doubt) that this has been overcome.

It seems to me, though, that its most important for the GNU kernel to
efficiently support the UNIX system interface.  Most of the software we
will want to run will have been developed under UNIX, and most of the
software we write, we will want to run on UNIX systems, too.  It would
be nice if we could support other, nicer interfaces too, but I'm afraid
that it would be counter productive.

I would certainly like to see the latest software technology applied to
the kernel implementation; I know of several successful kernels using
modular (TUNIS) object based (EOS) and other novel designs, while still
presenting a UNIX compatible interface.  I encourage a long (relative to
the utilities) kernel design phase, and would like to be a part of this.

_J. Greg Davidson		Virtual Infinity Systems, San Diego

greg@vis.uucp			ucbvax--| telesoft--|
davidson@sdcsvax.uucp		decvax--+--sdcsvax--+--vis
davidson@ucsd.arpa		 ihnp4--| celerity--|

P.S.  I'm going to be out of town and off the system until 5 December,
and hence unable to respond to your replies until then.

_JGD

Received: from MIT-PREP.ARPA by MIT-MC.ARPA via Chaosnet; 31 OCT 85  20:17:15 EST
Received: by MIT-PREP.ARPA (4.12/4.8) 
	id AA05769; Thu, 31 Oct 85 18:24:11 est
Date: Thu, 31 Oct 85 18:24:11 est
From: Richard M. Stallman <rms@prep>
To: info-gnu@prep
Subject: TRIX; target machines

TRIX is a kernel written at MIT, using remote procedure call among
domains as an architectural principle.  I hope to adapt it to serve
as the GNU kernel.

TRIX currently runs on the TI NU machine, a 68000 with virtual
memory but no demand paging.

Some people have asked about which models of machine GNU can
be expected to run on.  I cannot answer this.  I do not follow
product announcements, and do not know what most of the machines
on the market are like.  In fact, I've probably never even heard
of them.  It would be unproductive for me to think about these
things now, because now what I need to do is get GNU running
in the first place.

However, what you will probably need is a CPU that uses 32-bit
words and 32-bit pointers, free of weird memory architectures.
The 68000, 16000 and VAX fit this category.
You will probably need a meg of memory, but perhaps it will
run with less.
You will need a hard disk, and not a tiny one.
40meg ought to be ok.
You will not need virtual memory, I hope, but it is
very strongly recommended.

Any machine could in principle be supported if someone
wants to do whatever work it takes.  The only question is,
how much work, and do you want to do it?

Received: from MIT-PREP.ARPA by MIT-MC.ARPA via Chaosnet; 31 OCT 85  16:57:31 EST
Received: from ucb-vax.berkeley.edu (ucbvax.berkeley.edu.ARPA) by MIT-PREP.ARPA (4.12/4.8) 
	id AA05061; Thu, 31 Oct 85 16:55:04 est
Received: by ucb-vax.berkeley.edu (5.31/1.2)
	id AA24522; Thu, 31 Oct 85 13:54:26 PST
Received: by dali.ARPA (5.31/4.48)
	id AA00509; Thu, 31 Oct 85 13:43:09 PST
Date: Thu, 31 Oct 85 13:43:09 PST
From: rimey@dali.berkeley.edu (Ken Rimey)
Message-Id: <8510312143.AA00509@dali.ARPA>
To: info-gnu@mit-prep.arpa
Subject: Re:  TRIX arrives

What is TRIX?

Received: from MIT-PREP.ARPA by MIT-MC.ARPA via Chaosnet; 31 OCT 85  13:16:39 EST
Received: by MIT-PREP.ARPA (4.12/4.8) 
	id AA25841; Wed, 30 Oct 85 17:29:39 est
Date: Wed, 30 Oct 85 17:29:39 est
From: Richard M. Stallman <rms@prep>
To: info-gnu@prep
Subject: TRIX arrives

I've received a copy of the TRIX kernel sources
and I'm now starting to read them to find out what
I want to change.  The authors have decided to
distribute TRIX free.

Received: from MIT-PREP.ARPA by MIT-MC.ARPA via Chaosnet; 30 OCT 85  17:30:32 EST
Received: by MIT-PREP.ARPA (4.12/4.8) 
	id AA25841; Wed, 30 Oct 85 17:29:39 est
Date: Wed, 30 Oct 85 17:29:39 est
From: Richard M. Stallman <rms@prep>
To: info-gnu@prep
Subject: TRIX arrives

I've received a copy of the TRIX kernel sources
and I'm now starting to read them to find out what
I want to change.  The authors have decided to
distribute TRIX free.

Received: from MIT-PREP.ARPA by MIT-MC.ARPA via Chaosnet; 21 OCT 85  17:08:51 EDT
Received: by MIT-PREP.ARPA (4.12/4.8) 
	id AA00258; Sat, 19 Oct 85 14:15:28 edt
From: mit-ems!ima!haddock!stevel@mit-prep
Received: by mit-eddie.MIT.EDU (4.12/4.8)  id AA18697; Fri, 18 Oct 85 14:11:28 edt
Received: by mit-ems.ARPA (4.12/4.8)  id AA13469; Fri, 18 Oct 85 13:55:02 edt
Date: Fri, 18 Oct 85 13:55:02 edt
Message-Id: <8510181755.AA13469@mit-ems.ARPA>
Sender: mit-ems!haddock!stevel@mit-prep
Subject: (notes) junk mail                           
To: mit-prep!info-gnu@mit-prep

/* Written  1:10 pm  Oct 18, 1985 by notes@ima in haddock:mail */
/* ---------- "junk mail" ---------- */
Date: 18 Oct 1985 1100-EDT
From: cca!uucp (Unix to Unix Copy Program)
Sender: uucp at CCA
To: root at IMA
--------
Received: by cca-unix.arpa.ARPA (4.12/4.7) id AA01399; Fri, 18 Oct 85 11:00:58 edt
Date: Fri, 18 Oct 85 11:00:58 edt
Message-Id: <8510181500.AA01399@cca-unix.arpa.ARPA>
Mail failed.  Letter returned to sender.
From ihnp4!ucbvax!bbncc5.jr Thu Oct 17 00:13:00 1985 remote from ima
From: John Robinson <ihnp4!ucbvax!BBNCC5.ARPA!jr> <jr@bbncc5..UUCP>
Subject: Re: didn't you fix this?
In-reply-to: Your message of 17 Oct 85 13:32:41 EDT (Thu).
To: ihnp4!ucbvax!bbncc5.arpa!BostonU ihnp4!ucbvax!bbncc5.arpa!SysMgr
To: <root!bostonu.csnet@CSNET-RELAY.ARPA>
To: jsol!bostonu.CSNET@CSNET-RELAY.ARPA info-gnu@MIT-PREP.ARPA
Cc: wcattey@BBN-VAX.ARPA jr@BBN-VAX.ARPA dm@BBN-VAX.ARPA

Received: by ihnp4.ATT.UUCP id AA08570; 18 Oct 85 05:18:33 CDT (Fri)
Received: by UCB-VAX (5.28/5.13) id AA25941; Thu, 17 Oct 85 17:12:04 PDT
Received: from BBNCC5.ARPA (bbncc5.arpa.ARPA) by MIT-PREP.ARPA (4.12/4.8)  id AA01666; Thu, 17 Oct 85 20:05:34 edt
Message-Id: <8510180005.AA01666@MIT-PREP.ARPA>
We encountered this one, and traced to a 4.2bsd bug.  A fix (really,
workaround) is incorporated in emacs version 16.60, but the screen still
gets garbaged a little bit, but a redisplay will fix it.  To actually
fix it requires modifying stdio, which requires source license.  I can
help out the extra bit if you have source.

It is a race conditioin between child process signals and a write(),
which makes it hard to repeat.  We got it a lot with large screen
terminals (more write()'s so more to be hit).

/jr
--------
/* End of text from haddock:mail */

Received: from MIT-PREP.ARPA by MIT-MC.ARPA via Chaosnet; 19 OCT 85  14:14:16 EDT
Received: by MIT-PREP.ARPA (4.12/4.8) 
	id AA00258; Sat, 19 Oct 85 14:15:28 edt
From: mit-ems!ima!haddock!stevel@mit-prep
Received: by mit-eddie.MIT.EDU (4.12/4.8)  id AA18697; Fri, 18 Oct 85 14:11:28 edt
Received: by mit-ems.ARPA (4.12/4.8)  id AA13469; Fri, 18 Oct 85 13:55:02 edt
Date: Fri, 18 Oct 85 13:55:02 edt
Message-Id: <8510181755.AA13469@mit-ems.ARPA>
Sender: mit-ems!haddock!stevel@mit-prep
Subject: (notes) junk mail                           
To: mit-prep!info-gnu@mit-prep

/* Written  1:10 pm  Oct 18, 1985 by notes@ima in haddock:mail */
/* ---------- "junk mail" ---------- */
Date: 18 Oct 1985 1100-EDT
From: cca!uucp (Unix to Unix Copy Program)
Sender: uucp at CCA
To: root at IMA
--------
Received: by cca-unix.arpa.ARPA (4.12/4.7) id AA01399; Fri, 18 Oct 85 11:00:58 edt
Date: Fri, 18 Oct 85 11:00:58 edt
Message-Id: <8510181500.AA01399@cca-unix.arpa.ARPA>
Mail failed.  Letter returned to sender.
From ihnp4!ucbvax!bbncc5.jr Thu Oct 17 00:13:00 1985 remote from ima
From: John Robinson <ihnp4!ucbvax!BBNCC5.ARPA!jr> <jr@bbncc5..UUCP>
Subject: Re: didn't you fix this?
In-reply-to: Your message of 17 Oct 85 13:32:41 EDT (Thu).
To: ihnp4!ucbvax!bbncc5.arpa!BostonU ihnp4!ucbvax!bbncc5.arpa!SysMgr
To: <root!bostonu.csnet@CSNET-RELAY.ARPA>
To: jsol!bostonu.CSNET@CSNET-RELAY.ARPA info-gnu@MIT-PREP.ARPA
Cc: wcattey@BBN-VAX.ARPA jr@BBN-VAX.ARPA dm@BBN-VAX.ARPA

Received: by ihnp4.ATT.UUCP id AA08570; 18 Oct 85 05:18:33 CDT (Fri)
Received: by UCB-VAX (5.28/5.13) id AA25941; Thu, 17 Oct 85 17:12:04 PDT
Received: from BBNCC5.ARPA (bbncc5.arpa.ARPA) by MIT-PREP.ARPA (4.12/4.8)  id AA01666; Thu, 17 Oct 85 20:05:34 edt
Message-Id: <8510180005.AA01666@MIT-PREP.ARPA>
We encountered this one, and traced to a 4.2bsd bug.  A fix (really,
workaround) is incorporated in emacs version 16.60, but the screen still
gets garbaged a little bit, but a redisplay will fix it.  To actually
fix it requires modifying stdio, which requires source license.  I can
help out the extra bit if you have source.

It is a race conditioin between child process signals and a write(),
which makes it hard to repeat.  We got it a lot with large screen
terminals (more write()'s so more to be hit).

/jr
--------
/* End of text from haddock:mail */

Received: from MIT-PREP.ARPA by MIT-MC.ARPA via Chaosnet; 17 OCT 85  20:04:19 EDT
Received: from BBNCC5.ARPA (bbncc5.arpa.ARPA) by MIT-PREP.ARPA (4.12/4.8) 
	id AA01666; Thu, 17 Oct 85 20:05:34 edt
To: BostonU SysMgr <root%bostonu.csnet@csnet-relay.ARPA>,
        jsol%bostonu.CSNET@csnet-relay.ARPA, info-gnu@mit-prep.ARPA
Cc: wcattey@bbn-vax.ARPA, jr@bbn-vax.ARPA, dm@bbn-vax.ARPA
Subject: Re: didn't you fix this?
In-Reply-To: Your message of 17 Oct 85 13:32:41 EDT (Thu).
Date: 17 Oct 85 13:51:19 EDT (Thu)
From: John Robinson <jr@BBNCC5.ARPA>

We encountered this one, and traced to a 4.2bsd bug.  A fix (really,
workaround) is incorporated in emacs version 16.60, but the screen still
gets garbaged a little bit, but a redisplay will fix it.  To actually
fix it requires modifying stdio, which requires source license.  I can
help out the extra bit if you have source.

It is a race conditioin between child process signals and a write(),
which makes it hard to repeat.  We got it a lot with large screen
terminals (more write()'s so more to be hit).

/jr

Received: from MIT-PREP.ARPA by MIT-MC.ARPA via Chaosnet; 17 OCT 85  16:04:58 EDT
Received: from CSNET-RELAY.ARPA (csnet-pdn-gw.ARPA) by MIT-PREP.ARPA (4.12/4.8) 
	id AA21448; Thu, 17 Oct 85 09:37:25 edt
Received: from bostonu by csnet-relay.csnet id a005944; 17 Oct 85 9:32 EDT
Received: by bu-cs.ARPA (4.12/4.7)
	id AA26316; Wed, 16 Oct 85 20:51:41 edt
Date: Wed, 16 Oct 85 20:51:41 edt
From: BostonU SysMgr <root%bostonu.csnet@CSNET-RELAY.ARPA>
To: info-gnu@mit-prep.csnet, jsol@bostonu.CSNET
Subject: GNU EMACS problem


Ok, I have no idea how to repeat this one but it has happened a couple of
times now, maybe someone has a fix or has seen it or has a good suggestion
about what to do to provide better info for this bug-report.

Quite simply, suddenly I am in a state where only the first non-white
character displays, a screen of lisp suddenly looks something like:

(
	(
	(
	(
(
(

etc,
same for text or any other buffer I switch to, the lisp buffer was just
visually striking. The mode line is about the same with one digit displayed
further over, maybe being put in by time-display, the mini-buffer also
has only one char (I tried blindly typing in ESC-ESC(screen-width) and
got back:

8

which I assume means it still believes that I am 80 columns so it's not that
simple.

Suggestions to track this down welcome, I doubt very much it has anthing
to do with the terminal (just a VT220, after exiting it works fine w/o
adjustment and I don't know any sequence that would cause this behavior.)

The only thing I know is the last time it happened I had just paged to
the next article in *rnews*.

	-Confused at Boston University, Barry Shein

P.S. Act quick, I've got the thing suspended so maybe it will still be here
to do a core peek or something...Ok, I'll save a gcore, that's a start anyhow.



Received: from MIT-PREP.ARPA by MIT-MC.ARPA via Chaosnet; 17 OCT 85  09:37:18 EDT
Received: from CSNET-RELAY.ARPA (csnet-pdn-gw.ARPA) by MIT-PREP.ARPA (4.12/4.8) 
	id AA21448; Thu, 17 Oct 85 09:37:25 edt
Received: from bostonu by csnet-relay.csnet id a005944; 17 Oct 85 9:32 EDT
Received: by bu-cs.ARPA (4.12/4.7)
	id AA26316; Wed, 16 Oct 85 20:51:41 edt
Date: Wed, 16 Oct 85 20:51:41 edt
From: BostonU SysMgr <root%bostonu.csnet@CSNET-RELAY.ARPA>
To: info-gnu@mit-prep.csnet, jsol@bostonu.CSNET
Subject: GNU EMACS problem


Ok, I have no idea how to repeat this one but it has happened a couple of
times now, maybe someone has a fix or has seen it or has a good suggestion
about what to do to provide better info for this bug-report.

Quite simply, suddenly I am in a state where only the first non-white
character displays, a screen of lisp suddenly looks something like:

(
	(
	(
	(
(
(

etc,
same for text or any other buffer I switch to, the lisp buffer was just
visually striking. The mode line is about the same with one digit displayed
further over, maybe being put in by time-display, the mini-buffer also
has only one char (I tried blindly typing in ESC-ESC(screen-width) and
got back:

8

which I assume means it still believes that I am 80 columns so it's not that
simple.

Suggestions to track this down welcome, I doubt very much it has anthing
to do with the terminal (just a VT220, after exiting it works fine w/o
adjustment and I don't know any sequence that would cause this behavior.)

The only thing I know is the last time it happened I had just paged to
the next article in *rnews*.

	-Confused at Boston University, Barry Shein

P.S. Act quick, I've got the thing suspended so maybe it will still be here
to do a core peek or something...Ok, I'll save a gcore, that's a start anyhow.



Received: from MIT-PREP.ARPA by MIT-MC.ARPA via Chaosnet; 30 SEP 85  19:08:09 EDT
Received: by MIT-PREP.ARPA (4.12/4.8) 
	id AA03375; Mon, 30 Sep 85 16:53:38 edt
Date: Mon, 30 Sep 85 16:53:38 edt
From: Leonard H. Tower Jr. <tower@mit-prep>
Reply-To: tower@mit-prep.arpa
Organization: GNU Project, 1000 Mass. Ave., Cambridge, MA  02138, USA +1 (617) 876-3296
Home: 36 Porter Street, Somerville, MA  02143, USA +1 (617) 623-7739
To: info-gnu@mit-prep
Subject: media clipings desired

We would like to keep abreast of media coverage of the GNU project and the
Free Software Foundation.

If you run into a mention in a journal or newsletter, could you please
send a xerox to:
	Free Software Foundation
	Attn: L. Tower
	1000 Massachusetts Avenue
	Cambridge, MA  02138
or send me a reference via email.

Thanx,
Len

Received: from csnet-relay by MIT-MC.ARPA  4 Sep 85 20:18:10 EDT
Received: from case by csnet-relay.csnet id ae03530; 4 Sep 85 20:00 EDT
Received: by cwruecmp.UUCP (4.12/5.20); Wed, 4 Sep 85 12:06:50 edt
Date: Wed, 4 Sep 85 12:06:50 edt
From: rob <@csnet-relay.arpa,@CASE.CSNET:rob@nitrex.uucp>
To: INFO-GNU@MIT-MC.ARPA
Subject: mailing list addition



Can you add me to your mailing list?


rob robertson				decvax!cwruecmp!nitrex!rob.UUCP
1615 hazel drive			rob%nitrex%case@csnet-relay.ARPA
cleveland, ohio 44106			nitrex!rob@case.CSNET
					(216)  791-0922.MABELL	






Received: from csnet-relay by MIT-MC.ARPA 28 Aug 85 03:50:48 EDT
Received: from case by csnet-relay.csnet id a018576; 28 Aug 85 3:50 EDT
Received: by cwruecmp.UUCP (4.12/5.20); Tue, 27 Aug 85 20:54:55 edt
Date: Tue, 27 Aug 85 20:54:55 edt
From: rob <@csnet-relay.arpa,@CASE.CSNET:rob@nitrex.uucp>
To: INFO-GNU@MIT-MC.ARPA
Subject: addition to mailing list


Can you add me to your mailing list?


rob robertson				decvax!cwruecmp!nitrex!rob.UUCP
1615 hazel drive			rob%nitrex%case@csnet-relay.ARPA
cleveland, ohio 44106			nitrex!rob@case.CSNET
					(216)  791-0922.MABELL	



Received: from MIT-PREP.ARPA by MIT-MC.ARPA via Chaosnet; 27 AUG 85  16:06:23 EDT
Received: by MIT-PREP.ARPA (4.12/4.8) 
	id AA00763; Tue, 27 Aug 85 15:47:48 edt
Date: Tue, 27 Aug 85 15:47:48 edt
From: Leonard H. Tower Jr. <tower@mit-prep>
To: info-gnu@mit-prep, info-gnu-emacs-non-usenet@mit-prep
Subject: Any users of the Y compiler?

I am interested in talking to anyone who has used or worked with the Y
compiler developed at the University of Arizona by Hanson, Davidson,
Fraser, et.al.

I am particularly interested in hearing from hackers who have gotten
the distribution from Arizona, and installed and/or retargeted it.

GNU is looking into using parts of this compiler technology.

Thanx,
Len

Received: from csnet-relay by MIT-MC.ARPA 22 Aug 85 14:41:05 EDT
Received: from dartmouth by csnet-relay.csnet id a003381; 22 Aug 85 14:35 EDT
Received: by dartmouth.CSNET (4.12/1.20)
	id AA16336; Thu, 22 Aug 85 09:40:59 edt
Date: Thu, 22 Aug 85 09:40:59 edt
From: "David C. Kovar" <davidk%dartmouth.csnet@csnet-relay.arpa>
To: info-gnu-emacs@MIT-MC.ARPA, info-gnu@MIT-MC.ARPA
Subject: Addition to list

  Please add me to your mailing list. Thank you.
  -David


Received: from ur-cayuga.rochester.arpa by MIT-MC.ARPA 22 Aug 85 09:58:27 EDT
Received: from ur-seneca.rochester.arpa (ur-seneca) by ur-cayuga.rochester.arpa id AA18333 (4.12o); Thu, 22 Aug 85 09:57:47 edt
Received: by ur-seneca.rochester.arpa id AA26345 (4.12o); Thu, 22 Aug 85 09:57:15 edt
Message-Id: <8508221357.26345@ur-seneca.rochester.arpa>
Date: Thu, 22 Aug 85 09:57:15 edt
From: Steve Archer  <archer@rochester.arpa>
To: info-gnu@mit-mc.arpa
Subject: add to mailing list

Please add me to your mailing list.

Received: from MIT-PREP.ARPA by MIT-MC.ARPA 20 Aug 85 18:47:50 EDT
Received: by MIT-PREP.ARPA (4.12/4.8) 
	id AA02745; Tue, 20 Aug 85 17:30:51 edt
Date: Tue, 20 Aug 85 17:30:51 edt
From: Leonard H. Tower Jr. <tower@MIT-PREP.ARPA>
Message-Id: <8508202130.AA02745@MIT-PREP.ARPA>
To: info-gnu@mit-mc.ARPA
Subject: Administrivia: INFO-GNU and INFO-GNU-EMACS

GNU has just restructured the way the mailing list
"INFO-GNU@MIT-MC.ARPA" is maintained.  The effects
to list members are:

	- almost all members on both info-gnu and
info-gnu-emacs will generally receive only one copy of
a message sent to both lists.

	- info-gnu messages will automatically be sent
to the info-gnu-emacs list.

This text is also serving as a test message.

Len

Received: from MIT-PREP.ARPA by MIT-MC.ARPA via Chaosnet; 14 AUG 85  15:05:50 EDT
Received: by MIT-PREP.ARPA (4.12/4.8) 
	id AA00618; Wed, 14 Aug 85 14:44:17 edt
Date: Wed, 14 Aug 85 14:44:17 edt
From: Leonard H. Tower Jr. <tower@mit-prep>
To: info-gnu@mc, info-gnu-emacs@mit-prep
Subject: Opps: Wrong address for scheme support

The proper address for C scheme support is:
	bug-cscheme%mit-oz@mit-mc.arpa
Apologies for my mistake of assuming oz was directly on the ARPANET.

Len

Received: from MIT-PREP.ARPA by MIT-MC.ARPA via Chaosnet; 13 AUG 85  13:29:27 EDT
Received: by MIT-PREP.ARPA (4.12/4.8) 
	id AA03685; Tue, 13 Aug 85 13:12:23 edt
Date: Tue, 13 Aug 85 13:12:23 edt
From: Leonard H. Tower Jr. <tower@mit-prep>
To: info-gnu@mc, info-gnu-emacs@mit-prep
Subject: Scheme available in tar format via ARPA ftp

The Scheme team has made a tar file of the Scheme distribution
available.

It is available as a 3.3 megabyte tar file on mit-prep.arpa:
	/u2/scheme/dist.tar

Bug reports can be send to: bug-cscheme@mit-oz.arpa.

Len

Received: from MIT-PREP.ARPA by MIT-MC.ARPA via Chaosnet; 8 AUG 85  14:45:03 EDT
Received: by MIT-PREP.ARPA (4.12/4.8) 
	id AA19153; Thu, 8 Aug 85 14:24:20 edt
Date: Thu, 8 Aug 85 14:24:20 edt
From: Leonard H. Tower Jr. <tower@mit-prep>
To: info-gnu@mit-mc, info-gnu-emacs@mit-prep
Cc: cory@MIT-DAFFY-DUCK, dove@bugs-bunny, bandy@lll-crg.ARPA
Subject: Scheme is ftpable over the ARPANET

If you are on the Internet, you can at present copy the latest
distribution version of Scheme from host MIT-PREP.  The files are
present individually under the directory /u3/scheme/dist.

For those who missed the earlier announcement, Scheme is a a block
structured dialect of LISP.

For further information refer to: "Structure and Interpretation of
Computer Programs", by Harold Abelson and Gerald J. Sussman with Julie
Sussman, The MIT Press & McGraw-Hill Book Company, 1985.

The standard distribution should work on 32-bit machines under VMS,
BSD 4.1 & 4.2, ATT systems 3 and 5, HPUX, and TRIX.  Some
conditionalization may have to be done for other machines and
operating systems.

The Free Software Foundation distributes software in the hope that it
will be useful, but without any warranty.  No author or distributor of
this software accepts responsibility to anyone for the consequences of
using it or for whether it serves any particular purpose or works at
all, unless he says so in writing.

If you like the software developed and distributed by the Free
Software Foundation, please express your satisfaction with a donation.
Your donations will help to support the Foundation and make our future
efforts successful, including a complete development and operating
system, called GNU (Gnu's Not Un*x), which will run Un*x user
programs.  For more information on GNU and the Foundation, contact us
at:
  Free Software Foundation
  1000 Massachusetts Avenue
  Cambridge, MA  02138
Further questions can be directed to:
  Michael Zelyony 876-6819 or 876-3296

Received: from cvl.ARPA by MIT-MC.ARPA  6 Aug 85 23:32:33 EDT
Received: by cvl.ARPA (4.12/4.7)
	id AA16881; Tue, 6 Aug 85 23:32:20 edt
Date: Tue, 6 Aug 85 23:32:20 edt
From: gyuri@cvl (Gyorgy Fekete)
Message-Id: <8508070332.AA16881@cvl.ARPA>
To: info-gnu@mit-mc
Subject: Please add the following person...

to your mailing list: jim@maryland.arpa
Thank you.

Received: from MIT-PREP.ARPA by MIT-MC.ARPA  6 Aug 85 20:18:29 EDT
Received: by MIT-PREP.ARPA (4.12/4.8) 
	id AA02537; Tue, 6 Aug 85 20:16:12 edt
Date: Tue, 6 Aug 85 20:16:12 edt
From: Leonard H. Tower Jr. <tower@MIT-PREP.ARPA>
Message-Id: <8508070016.AA02537@MIT-PREP.ARPA>
To: info-gnu@mit-mc.ARPA
Subject: Another GNU Software Distribution

   The GNU project is organizing itself as the Free Software Foundation.
   We will continue with the same objectives:
     1) to create GNU as a full development/operating system.
     2) to distribute GNU and other useful software with source code and
   permission to copy and redistribute.

   The next distribution includes:
     GNU Emacs (Version 16.56) including manual source in TeX format.
     Bison - a parser generator compatible with Un*x's YACC.
     Scheme - a block structured dialect of lisp.

   We will send you a 1600bpi tar formated tape of this distribution,
   including full sources, if you send $150 to:
     Free Software Foundation
     1000 Mass Avenue
     Cambridge, MA 02138

   Make checks out to Free Software Foundation.

   The first edition of the GNU Emacs Manual is available separately at
   $15.00 a copy.

   Massachusetts residents please add 5% sales tax.  (These prices are
   subject to change without notice.)

   Further questions should be directed to:
     Michael Zelyony 876-6819 or 876-3296

   If you are on the Internet, you can at present copy the latest
   distribution version of GNU Emacs from the file /u2/emacs/edist.tar on
   host MIT-PREP.  After you unpack it, be sure to look at the files
   README and INSTALL.  The files are also present individually under the
   directory /u2/emacs/dist.

   The latest distribution version of Bison is in the file
   /u/rms/gnudist/bison.tar on host MIT-PREP.  The individual files for
   Bison are available under the directory /u/rms/gnudist/bison.

   For further information on Scheme refer to: "Structure and
   Interpretation of Computer Programs", by Harold Abelson and Gerald J.
   Sussman with Julie Sussman, The MIT Press & McGraw-Hill Book Company,
   1985.

   The distribution works under 4.2BSD Un*x running on Vax computers.  It
   is possible to reconfigure the software for other machines and
   operating systems.

   We distribute software in the hope that it will be useful, but
   without any warranty.  No author or distributor of this software
   accepts responsibility to anyone for the consequences of using it or
   for whether it serves any particular purpose or works at all, unless
   he says so in writing.

   If you like the software developed and distributed by the Free
   Software Foundation, please express your satisfaction with a donation.
   Your donations will help to support the Foundation and make our future
   efforts successful, including a complete development and operating
   system, called GNU (Gnu's Not Un*x), which will run Un*x user
   programs.  For more information on GNU and the Foundation, contact us
   at the above address.

Received: from UCB-VAX.ARPA by MIT-MC.ARPA 22 Jul 85 19:40:50 EDT
Received: from ucbernie.ARPA by UCB-VAX.ARPA (4.24/5.3)
	id AA03371; Mon, 22 Jul 85 16:35:22 pdt
Received: by ucbernie.ARPA (5.5/5.3)
	id AA11291; Mon, 22 Jul 85 16:40:53 PDT
Date: Mon, 22 Jul 85 16:40:53 PDT
From: phr%ucbernie@Berkeley (Paul Rubin)
Message-Id: <8507222340.AA11291@ucbernie.ARPA>
To: info-gnu@mit-mc
Subject: PD tutorial on awk

There is an article called "A Walk Through Awk" by Leon S. Levy of
Bell Labs, in SIGPLAN notices V18 #12 (December, 1983).  It does not
appear to say anything about the internals of awk.  Copies of SIGPLAN
Notices that I've looked at do not seem to carry any copyright notices,
but I didn't look at the December 1983 issue (I have a xerox of the 
article).

Date: Thu, 18 Jul 85 14:19:24 EDT
From: Ed Schwalenberg <ED@MIT-MC.ARPA>
Subject: Termcap avoiding ^@,^M,^J,^D,^S,^Q
To: INFO-GNU@MIT-MC.ARPA
Message-ID: <[MIT-MC.ARPA].580450.850718.ED>

Normal, "cooked" output from **Nix systems avoid ^D because it would cause
the stunt box in TTY33's to hang up the associated, built-on modem.  There is
no sane modern terminal (that is, more modern than TTY33's or Terminets) that
would barf at a ^D; if you were using such a terminal you wouldn't be
attempting to do cursor motion with it.  Similarly, ^M and ^J may be "cooked"
into other characters, possibly including padding; and whoinhell knows what
^S and ^Q may do.  Lastly, the whole termcap package is written in terms of
the old string package, where ^@ means end-of-string; it is avoided because
of that difficulty.

The idea behind all of the above nonsense was to make termcap work reliably
for most terminals in ALL **Nix tty modes (tandem, raw/cbreak/cooked, nl,
padding, etc.).  If you are using raw mode, outgoing characters are sent as
all 8 bits (you must do your own parity generation or can use the 8th bit for
things like Concept-LNZ's) and nothing else happens to your output.  Input
in raw mode is similar; make sure you mask the 8th bit if you aren't certain
that the user has a meta key.  No signals can be generated from raw-mode input.

Received: from MIT-PREP.ARPA by MIT-MC.ARPA via Chaosnet; 17 JUN 85  20:20:15 EDT
Received: by MIT-PREP.ARPA (4.12/4.8) 
	id AA02610; Mon, 17 Jun 85 20:16:08 edt
Date: Mon, 17 Jun 85 20:16:08 edt
From: Richard M. Stallman <rms@mit-prep>
To: info-gnu-emacs@mit-prep, info-gnu@mc
Subject: Job has been taken

The position for working on GNU full time is filled.
We are still looking for volunteers.

Received: from MIT-PREP by MIT-MC via Chaosnet; 6 JUN 85  17:01:03 EDT
Received: by MIT-PREP.ARPA (4.12/4.8) 
	id AA06408; Thu, 6 Jun 85 16:57:30 edt
Date: Thu, 6 Jun 85 16:57:30 edt
From: Richard M. Stallman <rms@mit-prep>
To: info-gnu@mc
Subject: One full-time hacker wanted

I have been offered money to hire one full-time system programmer
for the GNU project.  (Originally the offer was to support me,
but I seem to be able to support myself with a little consulting,
so I decided that hiring someone else would help GNU more.)

It needs to be someone able to work on the kernel or the compiler,
someone who can get a lot of reasonably understandable code written
and working, someone who has experience maintaining system software
that other people use.  I do not believe that knowledge of Unix
internals is a problem with these projects, as the internal organization
of our kernel and compiler are going to be different from Unix.

If you are interested, contact me and give me your phone number.
I can be reached at (617) 253-8830 or (617) 876-6819 most late afternoons/evenings.


Received: from csnet-relay by MIT-MC.ARPA 28 May 85 16:54:13 EST
Received: from bostonu by csnet-relay.csnet id ac01108; 28 May 85 16:47 EDT
Received: by bu-cs.ARPA (4.12/4.7)
	id AA06612; Tue, 28 May 85 15:29:25 edt
Date: Tue, 28 May 85 15:29:25 edt
From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa>
To: info-gnu@MIT-MC.ARPA, rms@MIT-PREP.ARPA
Subject: Re:  Unix questions to help with GNU Emacs

	^S/^Q	I would argue that if possible one should avoid
		sending these as they may be intercepted by intervening
		hardware with their usual meaning.

	^J,^M	I would assume some software is shy about the
		state of 'newline' mode either in the terminal
		hardware or the particular UNIX stty which could
		make these do unexpected things (esp LF->CRLF) and
		screw the cursor positioning.

I think all of this should be punted into Termcaps and it is up to
the user(s) to correctly set up their terminals and terminal descriptions
files. Also, adding a few more things to termcaps is no crime if it
misses something Emacs needs (I know, some descriptions have become too
large for the current routines, fix the routines or trim down the termcaps
somewhere else!)

For example, I added locally box/line drawing termcaps options to support
some software (eg: UL= for an upper left corner, as=/ae= for alternate
char set start/end) which all defaults to +- line printer stuff if
it doesn't find it. The point is, as long as it was a super-set it
broke nothing and few things are easier to ship to another site than
a termcap description/modification.

	-Barry Shein, Boston University



Received: from MIT-CCC by MIT-MC via Chaosnet; 28 MAY 85  12:36:08 EDT
Date: 28 May 1985 12:36:02-EDT
From: jfw at MIT-CCC
To: info-gnu@MIT-MC, rms@MIT-PREP
Subject: Re:  Unix questions to help with GNU Emacs

^D:  Certain >terminals< hang up when they receive ^D.  I believe that these
are printing terminals (given the age of the reference to such), but I don't
know this for certain (and given the brain death of certain terminal manu-
facturers...).  I guess no one has been obviously screwed by this on ITS because
(A) these terminals aren't common, or (B) if they mentioned it as a bug, they
were told their terminal needed a trip to sea (one way).

^M or ^J can be dangerous to send, because certain terminals are hardwired to
believe that ^J (for instance) means BOTH line-feed and carriage-return (i.e.,
the NEWLINE character on some terminals really MEANS *new* *line*).

^@ is avoided solely to get around the string termination problem.  I suppose
that if you used the mem???() routines (which Berkeley (and others) devised
to handle counted strings) in place of str???() routines, you could start
throwing nulls around, but that would (likely) entail a great deal of code
rewriting.

Received: from MIT-CCC by MIT-MC via Chaosnet; 28 MAY 85  09:41:21 EDT
Date: 28 May 1985 09:41:16-EDT
From: gill at MIT-CCC
To: rms@MIT-PREP
Subject: Re:  Unix questions to help with GNU Emacs
Cc: info-gnu@MIT-MC

I recall that the GE terminet-300, a printing terminal, would turn its own
power off when it received a control d. This had the side effect of dropping
the data terminal ready lead and hanging up the phone. As you can imagine,
sending poor users of such terminals control d's was second in popularity
only to infinite reverse line feeds as a high school prank.

I don't know of any CRT terminal that is sensitive in such a rude manner to
control d's, but then again, I haven't spent my life finding out.

In any case, most modems have no idea what sort of data is being fed through
them, and if the terminal accepts control d as a cursor positioning command,
then I see no reason not to give it what it wants.

I imagine some terminals are stupid enough to implement xon/xoff internally,
not allowing keyboard data to flow out if they receive an xoff. The more
frequent type of brain damage is a terminal turning off its receiving of
characters (honest!) when you send the computer a control s. Examples of
this fine art is the retro-graphics ``enhancement'' to the VT-100. 

The debate over not sending control j or control m is to desensitize
your system to the auto newline / carriage return settings of a
terminal. Some people still think it is useful for a single character
to cause both functions on output inside the terminal.

If you are using raw mode, then UNIX should not stand in your way
for any of these characters. Your comment about not sending nulls due to
string termination conventions is valid. I also remember that putchar ('\0')
didn't work in the old days (one had to write (1, "", 1) instead). This 
was in the pre-stdio days of the ``portable'' library, so it may not apply now.

If a UNIX system is being connected to through some non-transparant facility
(such as many dial-out programs) then there may be problems with the
``special'' characters you mention. The old UNIX ``cu'' had these sorts
of troubles, but more often with the ~ character than control codes (the
foreign system would send ~ sequences to tell the local cu program to redirect
input or output away from the terminal for immediate file copy, etc ...).

	- Gill

Received: from MIT-PREP by MIT-MC via Chaosnet; 28 MAY 85  03:04:06 EDT
Received: by MIT-PREP.ARPA (4.12/4.8) 
	id AA00599; Tue, 28 May 85 03:00:17 edt
Date: Tue, 28 May 85 03:00:17 edt
From: Richard M. Stallman <rms@mit-prep>
To: info-gnu@mc
Subject: Unix questions to help with GNU Emacs

The output from GNU Emacs is often contorted to avoid sending
any of the characters null, ^D, ^M, ^J, ^S and ^Q.  I want
to see if I can eliminate this contortion.

Since Emacs never wants to use tandem mode, can I assume it is
fine to send ^S and ^Q?

I recall hearing that sending ^D can make a phone hang up.
Is this true?  Is it true only with obsolete hardware?
What detects the ^D, the modem or the terminal or Unix?
If Unix, does it still do so if literal output is turned on?
Does it happen only with certain kinds of terminals?
Does this happen if the ^D is an argument (such as, a cursor position)
or only if ^D is a "top level" command?
Why would a terminal be designed to want ^D as an argument
in a command and also to drop a phone line if it is sent one?
Why haven't people been screwed by this when using ITS,
which makes no attempt to avoid sending ^D?

Can anyone suggest a possible motivation for avoiding sending ^M
or ^J as part of a cursor positioning command?  I cannot see
why this was done.

Is the null character being avoided only to avoid internal
confusion due to C string routines, or is there some other reason?

Received: from seismo.ARPA by MIT-MC.ARPA; 22 May 85 22:40:42 EST
Return-Path: <cbosgd!cbosgd.ATT.UUCP!mark@seismo.ARPA>
Received: from cbosgd.UUCP by seismo.ARPA with UUCP; Wed, 22 May 85 22:38:37 EDT
Received: from cbpavo.cbosgd.ATT.UUCP (cbpavo.ARPA) by cbosgd.ATT.UUCP (4.12/0.98.UUCP-CS.beta.4-27-85)
	id AA06652; Wed, 22 May 85 22:04:13 edt
Received: by cbpavo.cbosgd.ATT.UUCP (4.24/3.14)
	id AA09761; Wed, 22 May 85 22:09:39 edt
Date: Wed, 22 May 85 22:09:39 edt
From: cbosgd.ATT!mark@seismo.ARPA (Mark Horton)
Message-Id: <8505230209.AA09761@cbpavo.cbosgd.ATT.UUCP>
To: info-gnu@mit-mc.ARPA
Subject: @ sign

I feel obligated to point out that @ is not obsolete as a kill
character.  System V still comes with @ and # as defaults.  And
it is not true that "everyone" changes them - my experience is that
about 1/3 of the world still uses @, 1/3 uses ^U, and 1/3 uses ^X,
with only rare other characters.  Within AT&T, nearly everybody uses @
as a kill, since they use ! for their electronic mail.  (I'm not trying
to defend it, just pointing out reality.)

	Mark

Received: from sri-spam.ARPA by MIT-MC.ARPA; 22 May 85 14:31:42 EST
Received: from localhost by sri-spam.ARPA (4.53/4.16)
	id AA11709; Wed, 22 May 85 11:27:21 PDT
Message-Id: <8505221827.AA11709@sri-spam.ARPA>
To: BostonU SysMgr <root%bostonu.csnet@csnet-relay.ARPA>
Cc: INFO-GNU@mit-mc.ARPA, RMS@mit-mc.ARPA
Subject: Re: Version numbers
In-Reply-To: Your message of Wed, 22 May 85 13:03:32 edt.
	     <8505221743.AA11060@sri-spam.ARPA>
Date: 22 May 85 11:27:18 PDT (Wed)
From: sjk@sri-spam

    Date: Wed, 22 May 85 13:03:32 edt
    From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa>
    Subject: Version numbers

			.	.	.

    Just as an approach to the problem, a quick summary of punctuation
    chars as I see them:

			.	.	.

	    @	unused, old unix kill

Extract from the c-shell manual:

     Other operations treat variables numerically.  The `@' com-
     mand permits numeric calculations to be performed and the
     result assigned to a variable.

			.	.	.

     @
     @ name = expr
     @ name[index] = expr
          The first form prints the values of all the shell vari-
          ables.  The second form sets the specified name to the
                                                     ----
          value of expr. If the expression contains `<', `>', `&'
                   ----
          or `|' then at least this part of the expression must
          be placed within `(' `)'.  The third form assigns the
          value of expr to the index'th argument of name. Both
                   ----        ----- --             ----
          name and its index'th component must already exist.
          ----         ----- --

Just thought this should be clarified.

By the way, Barry,  do you only use the "root" on your machine?  Is there
some other address I should be mailing this to?

scott

Received: from Xerox.ARPA by MIT-MC.ARPA; 22 May 85 13:42:34 EST
Received: from Tokay.ms by ArpaGateway.ms ; 22 MAY 85 10:39:36 PDT
Sender: "Daniel S. Conde.osbunorth"@Xerox.ARPA
Date: 22 May 85 10:39:05 PDT (Wednesday)
Subject: Re: <None>
From: conde.osbunorth@Xerox.ARPA
To: RMS@MIT-MC.Arpa
cc: INFO-GNU@MIT-MC.Arpa
In-Reply-to: RMS%MIT-MC:ARPA's message of 21 May 85 21:45:45 PDT
 (Tuesday)



On Xerox IFS servrs, we could specify the lowest version with a "L"
version, and the highest with the "H". The separator is a "!", so we
have files like

foo.mesa!5

There's also a "delete N versions starting from the lowest" command.
"DELVER", which is useful. We have no facilities for automatically
"DELVER'ing", but that may be a nice attrtribute to stuff away somewhere
in the directory.

Dan Conde

Received: from csnet-relay by MIT-MC.ARPA; 22 May 85 13:30:23 EST
Received: from bostonu by csnet-relay.csnet id ad28193; 22 May 85 13:16 EDT
Received: by bu-cs.ARPA (4.12/4.7)
	id AA01014; Wed, 22 May 85 13:03:32 edt
Date: Wed, 22 May 85 13:03:32 edt
From: BostonU SysMgr <root%bostonu.csnet@csnet-relay.arpa>
To: INFO-GNU@MIT-MC.ARPA, RMS@MIT-MC.ARPA
Subject: Version numbers
Cc: rms@MIT-PREP.ARPA


First, I like the idea, whenever I come back from my Twenex I
realize how much I miss it.

Just as an approach to the problem, a quick summary of punctuation
chars as I see them:

[note that a few chars are ascii only if that matters]

	~	csh home
	`	eval cmd
	!	history
	@	unused, old unix kill
	#	csh,sh comment old unix erase	(@,# was TSO compat i think)
	$	eval variable
	%	job control
	^	old unix pipe char
	&	background
	*	glob match all
	(,)	grouping
	-	unused by shell but often a flag introducer
	_	UNUSED
	+	UNUSED, sometimes a flag introducer
	=	UNUSED
	[]	glob set match
	{}	UNUSED
	:	label
	;	separator
	'	quote
	"	quote
	|	pipe
	\	escape
	<	various i/o indirect
	>	ditto
	,	UNUSED
	.	UNUSED, often of significance to language tools
	/	not by shell, but path separator
	?	char match

Ok, I think that's all of them other than maybe ESC, looks pretty
grim, some of the chars are already overloaded (& and >& for example.)

The only pattern I see emerging here is an arithmetic one.
notice that the characters -,+,= are either unused or only at the
beginning of a string so....

	foo.bar-	lowest version
	foo.bar+	highest
	foo.bar=	exact match (or some such, like RMS said)


	-Barry Shein, Boston University



Date: Wed, 22 May 85 00:34:18 EST
From: Richard M. Stallman <RMS@MIT-MC>
To: INFO-GNU@MIT-MC
cc: rms@MIT-PREP
Message-ID: <[MIT-MC].513508.850522.RMS>

A bit to turn off version numbers in one directory is no problem.

A solution for lock files that are created and deleted
and don't want versions would be to have a permanent directory
entry that never really disappears and says "no version numbers
for this file".  Like what Twenex does for mail files.

The problem with . and .. is gross.  I'm amazed I didn't think of it.
It will have to be something other than period for suppressing version
number.  = sounds ok.

I think period to be allowed for separating version
numbers because period seems appropriate in terms of English
syntactic tradition.  The fact that I had no question in my mind
that period was the right thing to use in `emacs-15.24'
illustrates this tradition.  If it were only `=' and `.' it would
be ok; I could see switching to `emacs.15.34' or `emacs=15.34'.
`emacs=15=34' looks wrong.

Clearly `rm' itself could be made to use the lowest version,
or the highest version, by looking at the directory itself.
A more fundamental question is, what should `unlink' do?
Should it look for the lowest version or the highest one?
Does anyone see a reason to support either choice?

This brings up an important point: there ought to
be some way for the user to specify `the lowest version'.
Perhaps a final period could mean this, so
`foo' means the highest version of `foo', `foo.' means the lowest,
and `foo=' means `foo' exactly.  `foo.=' means `foo.' exactly,
while `foo=.' means the lowest version of `foo='.
Globbing should understand the two suffixes in appropriate ways.

I think that the most useful meaning of `lowest version'
is `lowest possible last version number within the highest
possible superversions'.  However, perhaps someone can think
of a suggestion that provides a syntax that allows specification
of `lowest' or `highest' for any individual version number.

