Re: Bug#776413: The priority of the ed package

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Lev Lamberov writes ("Bug#776413: The priority of the ed package"):
> Some time ago (see, #416585) the priority of the ed package has been
> changed to "optional", but ed is still a part of POSIX standard. For me
> personally the main issue here is the interpretation of "Unix-like" in
> the Debian Policy: "Important programs, including those which one would
> expect to find on any Unix-like system."

This makes it sound theoretical, or a question of breaking people's
`finger macros'.  That is indeed annoying.  But there is a much more
serious practical point, which Paul Hardy touches on.

There are still situations, even in modern systems, where the terminal
connection is limited to a serial line or equivalent.  In that
situation full-screen editors tend to malfunction because they do not
know the screen size (or, sometimes, terminal type).

Screen size mismatches can cause cursor positioning errors and thereby
mislead the user into making wrong edits.  This is particularly true
of editors like vi which make highly optimised use of the terminal,
minimising the amount of redraw.  I have actually experienced this,
although luckily it did not lead to any serious lossage. [1]

Conversely, ed works perfectly.  It can also be used as a pager (since
less doesn't work properly either).

Therefore since forever I am in the habit of using ed on serial
terminals.  I have generally only ed on the serial console of chiark,
for example.  That is a situation where I would not trusted nvi or vim
or emacs (all of which are of course available) to do the right thing.

I have also used ed on the serial console of a small embedded computer
for similar reasons.

This problem tends to arise in circumstances where it is inconvenient
to install ed.  On a recent occasion fixing another broken install I
had to resort to perl -i~ to edit /etc/apt/sources.list because ed
wasn't installed and I didn't want to trust nano or vi.

ed is also really good at handling cut-and-paste in both directions -
avoiding insertions of newlines, furniture, prompts, line wrap
indicators, etc..  That often turns out to be helpful in the
same situations.

So not having ed in the base system is a real nuisance.


[1] The demo.  Steps to reproduce:

 1. Open an 80x24 xterm on Debian stretch
      xterm -geometry 80x24 &

 2. In that terminal, set up the demo environment
      yes | nl -ba | head -50 >t
      stty rows 80
    Now you are simulating a serial line setup where the window
    on the computer at the near end of the line (ie, the one
    you are physically sat at and whose keyboard you are using)
    is smaller than believed by the remote computer (the embedded
    computer, or the machine in the colo, where you are trying to
    fix things by editing files).

 3. Run your favourite editor
      nano t
      vim t
      emacs -nw t

In particular, with vim: observe that what seems to be displayed is
lines 28 onwards.  Say `j' twice to go to line 30, `i' to insert at
line 30, insert the letter `x', press ESC, ZZ.  If you now
   grep x t
you will see that it was inserted at line 3.  The file looks nothing
like it did on screen.

With nano: you will see an apparently normal nano display.  Try
page-down a couple of times and observe that it is impossible to view
the rest of the file.  If you then type some inserting characters they
appear in the menu, obscuring how to exit.  If you say ^X, remembering
that that is how to exit, you are offered No or Cancel but the
question is missing.

With emacs: you will see an apparently blank file.


Analysis:

None of these programs are expected to work properly in this
situation.  The displays are very seriously misleading and will
generally lead to the user corrupting the file if they don't notice.
In the case of nano one might notice too late that things are going
wrong and be stuck in the program because the reminder of the unusual
exit keystroke has gone!

Generally the symptoms are less bad when the terminal is bigger than
the editor thinks, but there is certainly no guarantee by any of these
programs that they will not seriously malfunction in that case.  (Such
a guarantee would be almost impossible to make since it would depend
on unknowable terminal behaviours.)

Careful and experienced users will have learned to avoid all full
screen programs over ad-hoc serial sessions.  If that is too
inconvenient, it is possible to manually `stty' to set the terminal,
being sure to get the numbers right, or rely on a program like
resize(1)).  But then one must remember not to resize the window !

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.