"ed" under 4.2BSD

wmartin at Almsa-1.ARPA wmartin at Almsa-1.ARPA
Wed Apr 18 00:13:47 AEST 1984


From:      Will Martin -- DRXAL-RI <wmartin at Almsa-1.ARPA>

We are running 4.2BSD on a VAX 11/750. I have noticed the following
in the BSD manual pages for "ed", dated 14 Sept. 79, in both the
on-line and printed versions of the manual supplied with the code:

     (., .)u
          The undo command restores the buffer to it's state
          before the most recent buffer modifying command.  The
          current line is also restored.  Buffer modifying com-
          mands are a, c, d, g, i, k, and v. For purposes of
          undo, g and v are considered to be a single buffer
          modifying command.  Undo is its own inverse.

          When ed runs out of memory (at about 8000 lines on any
          16 bit mini-computer such as the PDP-11) This full undo
          is not possible, and u can only undo the effect of the
          most recent substitute on the current line.  This res-
          tricted undo also applies to editor scripts when ed is
          invoked with the - option.

***End extract*** [Garbled grammar thus in original...]

It seems that the "u" subcommand on this system (and on another 4.2BSD
system I have accessed, too) is locked in the "restricted undo" mode
described in the second paragraph. It doesn't matter how tiny the file
being edited is -- "u" will only undo the last substitute command, will
not reverse itself, and does not undo the other commands listed in te
first paragraph.

1) Is this normal, or is something broken?

2) Can someone at the user level control the "u" capabilities?

3) If system-level action is required to fix this, what is involved?

It may be that I will have to teach "ed" to some of our personnel who
will have only a printing terminal for a while, so I'm trying to
make sense of some of its peculiarities. Advice is appreciated.

Will Martin

PS - I know that there are better "ed"s out there, as several people
mentioned them in responding to an earlier inquiry I had made about
the "n" subcommand. However, it is unlikely that we will be changing
"ed", so I am more interested in coping with the one we have than in
what better replacements I {could/should/might} be using. Thanks - WM



More information about the Comp.unix mailing list