Using A Piece Of Paper As A Display Terminal - ed Vs. vim

2020-10-05 - By Robert Elder

Introduction

     This article will focus on discussing why the ancient text editor 'ed' works the way it does.

     Despite having its roots in the late 1960s, the 'ed' editor is still installed by default on most modern Linux distributions.  Although there are few practical use cases for this editor today, it can still be meaningful to learn how 'ed' works since other Unix tools like vim, grep or sed have features that are significantly influenced from 'ed'.

What Are You Waiting for?

     If you try running the 'ed' command with or without a file argument, you'll see something that looks like this:

     If you're waiting for something to happen then you'll be waiting a long time.  That's because 'ed' is waiting for you to do something!  The 'ed' program doesn't work like other command-line text editors such as vim or nano.  The luxury of being able to print the contents of the current file to the terminal is something that 'ed' takes very seriously.  That's why you need to explicitly give 'ed' a command to tell it to do so!

     For example, if you want to print out an individual line in the file, you can just type the line number and press enter.  If you want to append text, use the single-letter command 'a' on a line by itself to enter 'append' mode.  Once you're done adding text, write a '.' character on a line by itself and press enter to stop adding text to the file.  To review all the lines in the file, you can use the command '1,$p'.  Finally, once you're done editing the file, you can use 'wq' to exit:

1
Hello World.
a
Here is some more text.
.
1,$p
Hello World.
Here is some more text.
wq

Why Is 'ed' So Hard To Use?

     To make sense of why this editor is so hard to use, it make sense to think about the way in which people interacted with computers in the early days of computing.  Around the time when 'ed' was created, it was still common for computers to print their output on paper instead of electronic screens!  These early output devices were called 'teleprinters', often abbreviated as TTY.  The term TTY is still used on most *nix systems to this day, and if you run this command, you can probably see some of the virtual TTY devices on your system:

ls /dev/tty*

     This ancient model of sending an infinite stream of characters (sent serially) to a 'terminal' or 'teleprinter' device that 'prints' or 'renders' them is still used today.  It is even used by more modern terminal programs like vim or nano!  You might not believe that vim works this way because it displays all kinds of information at the top and bottom of the terminal.  Vim also lets you scroll up and down or open up screen splits etc.  You can't possibly send the output of vim to a printer, right?  Yes, you can and that's exactly what we're about to try.

The 'script' Command

     The 'script' command lets you capture all output during a terminal session and save it to a file.  This is a great way to log the output when you're running through a sequences of commands that you need to keep track of, but you can also use it to capture everything that gets output to the terminal during a vim session:

script

     After running the 'script' command try opening a vim session.  After doing a few things in vim, quit and then run the 'exit' command in the shell to exit the 'script' session to finish logging:

exit

     All of the output from the terminal session is now saved in a file called 'typescript'.  Here's an image of what some of the output in the script looks like:

     Many of these seemingly gibberish symbols are actually ANSI Escape codes.  These are the secret to how vim (and all other terminal applications) can use a serial output to print all sorts of interesting user interfaces.  Most importantly, some of these escape sequences allow you to move the printing cursor around to arbitrary positions.  That's how vim can keep some text pinned at the bottom or top of the terminal while also giving the illusion that you're scrolling 'up' or 'down' in the file.  Some escape codes also control the foreground and background colours.

      In the old days, these escape codes were not actually processed by the CPU.  The were instead interpreted by the 'terminal' monitor device itself.  In other words, the oldest 'terminals' can be thought of as physically separate devices that received a serial stream of text, cursor movement instructions, and color changing instructions.  On a 'modern' computer, every 'terminal' window that you open is basically a software emulation of an ancient physical device that you can imagine to look like a small and bulky CRT monitor.  Today, these escape codes are processed by the CPU of your laptop or desktop computer inside these software emulated 'terminals' in your graphical desktop environment.

Vim

     So, what's stopping us from trying to render the output of vim on a piece of paper to pretend that we're in the year 1969?  Nothing!  Here's is what the output of vim looks like when I try to render it using my laser printer:

     The reason that this output doesn't look very useful is because my printer isn't expecting to be used as a display terminal for vim.  It doesn't know how to deal with all the ANSI escape sequences and we end up with this weird looking mess.  Do you see the '?2004h' part near the start of the output?  You can look that up and see that it's an ANSI escape sequence to 'Turn on bracketed paste mode'.  It is an exercise left to the reader to look up the rest of the ANSI escape sequences shown on the page above.

     Interestingly, my printer seemed to choke when I printed this and got stuck saying 'data remaining' until I printed a blank test page.

     I didn't bother investigating, but I assume one of the control sequences confused the printer and made it think it was still waiting on data from the computer.

Ed

     And here is what using ed would look like if you were only able to render its output on a piece of paper:

     Since 'ed' doesn't print any ANSI escape sequences, my printer prints this with no problems!

     Based on the two experiences described above, which editor do you think you'd prefer if you had to print all the output on paper?

Conclusion

     If you decide to try and learn 'ed', you'll find that the man pages and the '-h' flag are not very helpful.  Instead, you should check out the 'info' pages since that's where you'll find out all the details of different editor modes and single-letter commands are:

info ed

     After you play around with 'ed' for a while, you'll realize that it acts almost like a command-line shell in itself.  The only difference is that the environment in which you're working is a file instead of the user space of your operating system.  Every little i/o operation on the file is implemented as a command that requires as little information as possible.  This makes complete sense when you have to print everything to paper!

     Imagine working on a file with modern Vim where your output always goes to a printer.  You now decide to open a log file to check what's on the last line and immediately, your printer starts churning a full page of material.  Oops, you opened the wrong file.  Try another file, and again, oops!  Wrong file again!  That's a lot of wasted paper.  What is it with these millennials and their fancy text editors that just print every line automatically!  I remember the good old days when the users had control over their systems, and programs wouldn't just do whatever they want without asking!

     In conclusion, the reason why the 'ed' command works the way it does was due to the higher resources constraints that existed at the time.  Features like electronic display terminals and ANSI escape sequences were not in common enough use at the time when 'ed' was created, so there was no reason to consider using them.  Instead, a shell-like command-line interface for editing files made way more sense.

Can You Use 'ed' As A Drop-in Replacement For vim, grep & sed? Published 2020-10-15	$1.00 CAD Terminal Block Mining Simulation Game	A Surprisingly Common Mistake Involving Wildcards & The Find Command Published 2020-01-21	A Guide to Recording 660FPS Video On A $6 Raspberry Pi Camera Published 2019-08-01
The Most Confusing Grep Mistakes I've Ever Made Published 2020-11-02	Use The 'tail' Command To Monitor Everything Published 2021-04-08	An Overview of How to Do Everything with Raspberry Pi Cameras Published 2019-05-28	An Introduction To Data Science On The Linux Command Line Published 2019-10-16