38

The line editor ed in UNIX/Linux has a "command mode" and an "insert mode" and there is no visual way to tell which mode you are in. However, there is a -p option that causes it to display a prompt when you are in command mode, which is very helpful.

Why is the default to have no prompt? Masochism?

JoelFan
  • 2,117
  • 2
  • 15
  • 18
  • 17
    All of classic Unix is extremely terse. Notice also that most commands like cp or rm return no message upon completion, unless there's an error. The first terminals were usually printing teletypes running at an excruciating 110 baud. Every character printed meant time, paper, ink and mechanical wear. So extreme frugality was the practice. – RETRAC Dec 07 '19 at 17:51
  • 2
    Please write answers in the answer section – Lightness Races in Orbit Dec 08 '19 at 19:50
  • 6
    @LightnessRaceswithMonica I commented because sadly, it's not really an answer. Just some background context. I don't know why ed doesn't even have a prompt, given that e.g. the shell does. Just wanted to point out that terseness is a tendency in Unix systems. – RETRAC Dec 09 '19 at 17:46
  • When you use ed in scripts (for example to merge two files, note diff has a mode that outputs ed scripts) a prompt would really be a nuisance. – tofro Nov 12 '22 at 13:43

8 Answers8

43

Having used ed years ago on printing terminals (such as teletypes and DECwriters), I think the reason for having no prompt was that on pressing RETURN after one command, you didn't have to wait for a prompt to be printed before starting to type the next command.

Similar considerations made it better for ed to have ? as the only error message: you would have worked out what the mistake was long before a longer error message had finished printing.

Mike Spivey
  • 870
  • 7
  • 9
  • 7
    Actually, ed had a second error message: it printed ?tmp if its temporary file was full. – Mike Spivey Dec 06 '19 at 12:36
  • Right... and those error messages go to stderr. – O. Jones Dec 07 '19 at 21:10
  • @O.Jones: Not in the Sixth Edition. – Mike Spivey Dec 07 '19 at 22:40
  • 1
    On a system which echos characters when they are read, the delay wouldn't be an issue, but you raise a good point about systems which echo them as they are typed--an approach which may be good from a CPU usage perspective, but is bad as a UI. – supercat Dec 18 '19 at 23:24
  • 7
    I think you misunderestimate the psychological effect of trying to type on machines that noisy while holding the changes you'd planned in your head! – Mike Spivey Dec 19 '19 at 20:01
  • And the same reasoning went for TECO as well ... – davidbak Jan 09 '23 at 23:05
  • Having used plenty of programs that did prompt, I should say that it's not necessary to 'wait for the prompt'. Full duplex with typeahead does the job. Deferred echo even has the output looking coherent. – dave Jan 09 '23 at 23:29
  • @another-dave: Does Unix cooked echo include any mechanism for deferring echo in such a manner to produce coherently-merged prompts? – supercat Jan 12 '23 at 18:53
24

When I was a lad, the only reason ed was included at all in our environment is because it was used by the standard system scripts.

Originally, having to clean the 'prompts' out of ed output to clean up the data would have just made everything more difficult -- much more difficult.

Later, having ed default to something different would have just broken all the existing scripts.

necromancer2
  • 241
  • 1
  • 2
17

However, there is a -p option that causes it to display a prompt when you are in command mode

The -p option is meant to set a different prompt. When used, a side-effect is that ed starts in addition with prompt enabled.

Why is the default to have no prompt?

There is a default, * (asterisk); it's just not switched on. Prompt display can be toggled by applying a P command (*1).

Ed is meant as well for automated (scripted) use (*2). Having the prompt displayed for each command entered is at least annoying; on a real TTY it will waste a lot of paper.

To display no prompt by default seems sensible in an early environment, doesn't it?

In addition, it might be good to keep in mind that programming back then, especially when done online, was handled mostly in the head, not on a screen or alike. When using ed, one had to have a proper image present. Printing the whole file or just parts thereof would eat up a lot of paper and even more important time. Listing just a page would easily take a minute or two.

With that background it's rather trivial to keep aware what mode one is in. After all, it's not complicated, as default is command and input is only activated on request.

*1 - The prompt is a rather new addition as Stephen Kitt mentioned.

*2 - I always loved the feature to 'open' any shell command as an input 'file'.

In fact, ed even predates next to all other Unix tools as well as basic output direction itself (which was a shell feature until pipes were added in V3 (?)). So the standard way to capture a program output was to 'open' it as ed input file and save it as text file:

$ ed
r !ls -l
w directory_listing
q
JoelFan
  • 2,117
  • 2
  • 15
  • 18
Raffzahn
  • 222,541
  • 22
  • 631
  • 918
  • 5
    “To display no prompt by default seams sensible in an early environment” — indeed, although it might not be obvious why nowadays ;-). Incidentally, older versions of ed don’t support prompts at all, they’re a somewhat recent addition. – Stephen Kitt Dec 05 '19 at 20:15
  • @StephenKitt was it? I never thought about - in fact, I never used P at all, just looked it up a few minutes ago. Do you know when it was added? – Raffzahn Dec 05 '19 at 20:28
  • 4
    I’m not sure when it was added; even the V10 manpage doesn’t mention it, I think it came from BSD — 3BSD has it. So “somewhat recent” for some values of recent, around 40 years ago ;-). – Stephen Kitt Dec 05 '19 at 22:30
  • 4
    Browsing through minnie.tuhs.org, in V6 (1975), 'P' is an error. In V7 (1979) 'P' was a synonym for 'p'. In Sys III (1982), 'P' toggled the prompt. – Kelvin Sherlock Dec 05 '19 at 22:48
  • 1
    @KelvinSherlock Thanks. :) I guess we all have forgotten how incompatible various Unix versions and derivatives were over time. – Raffzahn Dec 06 '19 at 01:48
  • Wow, did not know about the lack of output redirection. – chepner Dec 06 '19 at 16:59
  • @chepner Even Unix did need some time to develop. But ed, being really one of the very earliest functions at all, clearly shows the direction with it's inclusion to execute a command and read its output. – Raffzahn Dec 06 '19 at 18:46
  • The P command was first found in UNIX System III. I think the -p option was first added in UNIX System V. – Greg A. Woods Mar 21 '20 at 19:23
7

The -p option is a late addition. I did some checking and the Seventh Edition man page for ed doesn't mention the -p option, but it does appear in the Ultrix 4.2 man page. Fifth Edition Unix also doesn't mention a -p option, but it does say that if ed is invoked as a login shell (i.e. the program name provided in argv[0] is "-") that it will enable a * prompt. This was presumably done in support of the early use of Unix as a text editing system.

I am guessing that the -p option was added to provide an easier way to enable a prompt without jumping through the required hoops to invoke ed with arg[0] set to "-". But by that time, I suspect that very few people were still using ed for interactive editing: vi/ex and Emacs would have taken over for most. If you were still using ed, you were either familiar with it already due to using it for many years (in which case you wouldn't need the prompt), or you were using it non-interactively (giving it input from a file) and you wouldn't have wanted prompts anyway.

Toby Speight
  • 1,611
  • 14
  • 31
Ken Gober
  • 11,427
  • 1
  • 40
  • 56
7

Just when you think this question has been put to bed It raises its head yet again with greater authority. This time, from the horses mouth - so to speak - Bill Joy himself. It is an interview with the UNIX Review in the web masoleum called archive.org:

Excerpt from an interview of Bill Joy of Sun Microsystems by Jim Joyce of UNIX Review. Entitled: Interview with Bill Joy the text appeared in the August 1984 issue of Unix Review magazine.

https://web.archive.org/web/20120210184000/http://web.cecs.pdx.edu/~kirkenda/joy84.html. Bill is being asked about how things evolved around him and here they have arrived at the subject of usability in the context of limited hardware capability at that time. They start out by joking that 'cat' is the most efficient editor for the job at that time ... ...

REVIEW: Real programmers use cat as their editor. JOY: That's right! There you go! It is too much trouble to say ed, because cat's smaller and only needs two pages of memory - plus you're not likely to get swapped out. That's why ed didn't prompt, you know. The performance of the system was just horrible. It would swap things out randomly and do all sorts of things. In ed you might type "a", but have no idea how far behind the system was. And it didn't matter, and long as it didn't get more that a few hundred characters behind and start throwing lines away without telling you.

Typically it wasn't that bad. If it had been prompting, you would have hit carriage return and wait for the prompt, and it would have taken three seconds to comment. That's something we noticed when we put em up. We put in the prompt and suddenly realized it had to go through the operating system.

I think UNIX has lived with grace for years. We've had the grace of people not being able to tell when the system was doing a bad job of scheduling the CPU. Now we can't hide behind time-sharing.

...

There's plenty more before this point in the article but it would be off-topic. So they had noticed that a prompt which was in the 'em' editor they were also working on, was vulnerable to UNIX swapper stack trashing and the prompt response queue was also too narrow to timeously notify the user ...

So they did not implement an 'ed' prompt on account of performance under UNIX multi-user time share loads, and also over hardware limitations of that era.

user26389
  • 86
  • 1
  • 1
  • 1
    It might have been helpful if ASCII had included flow-control characters to operate a four-way "ready" indicator which would indicate ready to receive an arbitrary amount of input, ready to receive a line, ready to receive a character, or not ready to receive any. A mechanically-encoded keyboard like the ASR-33 could have provided tactile feedback to the operator when an intended keystroke wouldn't be able to register, while electronic keyboards could use a light to indicate readiness and a beep to indicate rejected keystrokes. – supercat Jan 09 '23 at 22:54
  • 3
    @supercat - tactile feedback from an ASR-33? Those things were nothing BUT tactile feedback! Your hands shook, your fingers were numb from pressing so hard, your feet shook through the floor - if they had any more tactile feedback your fingers would fly right off your hands! (And the noise ...) – davidbak Jan 09 '23 at 23:05
  • 1
    good find, that interview! – davidbak Jan 09 '23 at 23:06
  • 1
    @davidbak: From what I recall, if one tried to type two characters more than 1/10 second apart, the ASR-33 wouldn't let the second key descend until the mechanism had finished cycling after the first character. Also, if I recall, keypunches and mechanical typewriters could be configured with margins, and lock the keyboard--in a manner that could be clearly felt--if someone typed too much. – supercat Jan 09 '23 at 23:19
5

Looking at the previous answers I see everyone has missed an essential feature most system run level 1 commands, and that is that they were amenable to piping. The non-interactive mode is therefore the default in ed, ex, sed, awk, grep etc

TFTP (Trivial FTP) is also another good example of a stripped down version of FTP used in disk-less boot-up processes to boot from a remote network boot image. No user prompts are emitted as is done in the full-blown FTP.

MKhomo
  • 462
  • 3
  • 8
  • 2
    I see why you wouldn't prompt when stdin was not a tty, but that in itself doesn't explain the lack of a prompt when stdin is a tty. – dave Dec 08 '19 at 21:00
  • It is not easy to apprehend the situation of prior eras. An earlier answer mentioned that the editing was done in one's head, not on the teletype. That applied to many other subtleties. Ed column numbers matched the imagined document, and column 1 was where imperative text went just as in the intended memory copy. So whence the prompt? – MKhomo Dec 08 '19 at 21:50
  • It's easy enough to apprehend a prior era when one remembers actually driving a teletype in said era. :-) Apropos 'column numbers', sure, the first character entered on a line was logically "column 1", but since teletypes don't actually have numbered columns, there's no problem if "column 1" is printed after a "*". In any case, I understood the question to be about a prompt in command mode, not in text-input mode, so column numbers aren't really a consideration. – dave Dec 08 '19 at 21:56
  • I lost some edits after the prompt? question in my prior comment. But perhaps I could reverse the apprehension issue by asking what purpose one would suggest the prompt would / should serve within the scope of 'ed' functionality which does recognize line and column numbers? As far as I remember it was to perform edit actions on the 'ed' buffer, although the bang (!) allowed escape to shell. Don't recall if 'ed' supported multi-buffer yank / put etc – MKhomo Dec 08 '19 at 22:20
  • I see no useful role for the prompt when in insert mode. I think a prompt is useful in interactive command mode since it conveys "done that thing, ready for the next thing". But then, I'm just describing all of the various non-display-oriented editors used. – dave Dec 08 '19 at 23:39
  • That would be an overlap with interpreted interfaces such as the erstwhile command-line Basic environment where the command mode would include shell directives like 'run', 'join' etc, in addition to editor directives like 'append', 'change', 'substitute' a la ed. The former are not in the scope of ed. But I would admit the use of a line 'status' prompt which indicates where in the edit cycle one is. You see it in shells where the prompt changes on continuation lines or in fix command (fc) edits of prior commands from history. I am not sure if the more recent -p goes that far. – MKhomo Dec 09 '19 at 01:43
  • Added the FTP / TFTP contrast to further illustrate removal of user prompts in sys level 1 (sbin) command variants. – MKhomo Dec 18 '19 at 21:48
  • I don't think TFTP is a stripped down version of FTP, it's an entirely different protocol. TFTP (as a program) gets the file and exits, there's no commands, so it would make no sense to prompt (just as for eg ls). – JeanPierre Dec 18 '19 at 22:14
  • @another-dave: Although it has become commonplace for programs to recognize whether stdin is redirected and adjust behavior appropriately, I don't think that was always the case (IMHO, console input should always have been recognized as a separate stream from stdin, but requests to fetch data from non-redirected stdin should have received data from the console stream). – supercat Dec 18 '19 at 23:22
  • Well, in my personal experience, I wrote code that way in 1975 (under RSX-11M), and it was commonplace then. – dave Dec 19 '19 at 01:00
  • @another-dave The George Coulouris retrospective I added as new answer here sheds plenty light at what you were saying DEC was obviously far ahead of the game in real time tty response and UNIX came into it from a time share culture; but slowly caught on, at least in the manner GC explains the evolution of UNIX editors (not RXS). – MKhomo Nov 09 '22 at 23:29
  • Pretty much every DEC OS I used, starting with TOPS-10, had a 'teco mode' in the terminal driver, in order to support character-interactive text editors. (It might have also been called 'ddt mode', since the debugger was character-interactive too) – dave Nov 10 '22 at 00:31
  • Reminds me of a Tech Roadie I worked alongside some three decades ago on a project converting VTAM to DEV VT 220 via screen scraping middleware. He was from DEC Real Time controlling rolling mill motors and the rest of it. But his first day on the job was this unusual need to check IEEE Floating point on the HPUX host and VT220 emulators. One of his test harnesses made our drab monochrome displays into a Keleidoscope Festival with Disco lights. It was amazing to see the power of the DEC terminal drivers that usually did very little on UNIX tty watch and Mainframe Peripheral Processing Devices – MKhomo Nov 10 '22 at 09:53
  • Ran out of the edit time window. Above read DEC VT220 not DEV VT220; and closing phrase refers to their official Marketing name (to calm IBM nerves) Peripheral Data Processors (PDP). – MKhomo Nov 10 '22 at 10:03
3

Because of the universality of printing terminals when ed was current. An editor prompt on each data line would have consumed space on the paper, which would have cut that much off of what you could type into each line, and see. Printing terminals didn't autowrap, and typing blindly off the end of the line was Unpleasant. Even if they had autowrap, that would have consumed more paper, and reduced the correspondence (on paper) between what you had typed the first time, versus what you'd see if you then printed it again (sans prompts). (Conservation of paper was a significant issue, even if it was just to prevent you from becoming mired in an overlarge pile of paper from your session.)

jimc
  • 107
  • 4
  • I'm not talking about data lines. I'm talking about command mode. The point is to be clear about what mode you're in. By default it doesn't give you a prompt even in command mode. It's very confusing to not be sure whether you're in command or data entry mode. – JoelFan Mar 18 '20 at 16:48
  • 3
    If you weren't sure you would just scan up the paper to see what you had done recently, it really wasn't too hard to tell what mode you must be in at the moment. Also, most text interpreted as commands would piss ed off in some way, and the "?" was a pretty good clue that you'd guessed wrong. – jimc Mar 18 '20 at 16:52
  • 4
    Life on a 10-cps printing terminal really was different in a lot of ways, it's hard to envision this if you've never had to live it. – jimc Mar 18 '20 at 16:57
2

A bit late in the day, but here's a timeless broad-brush non-explanation that quashes the OP question. It's from Queen Mary's College Univ of London - of all places.

http://www.eecs.qmul.ac.uk/~gc/history/

Someone asked for a synopsis; so I'll do it in little bits as per reader reactions. First the one-page story. Two personalities appear in the Unix Editors story but if one goes back a little (during MULTICS predecessor phase) one discovers more central actors. In this case it is George Coulouris (GC), part of the UK side of the MULTICS. Folklore (and GC confirms here) has it Ken Thompson (KT) wrote ed and was quite happy not seeing the final / intermediate editing result as he merely kept it in his head. Input was teletype and 'seeing' it meant teletype printing the buffer which was a distraction (as would be the printing of a prompt). The UK crowd had a small Amiga dedicated-cpu terminal/console being developed that provided more capability which GC exploited at Queen Mary College at Univ of London, and named it "ED for Mortals" as a rejoinder and in deference to KT's standing and Editor (ED). So the quibbles over return prompt take on a different level of importance for that time. And this was during MULTICS and KT was the author of the ED being discussed here while QC of EM.

Secondly, GC and his collaborators across the British Computer Science fraternity had begun addressing the editing into rapid response one character at a time as an improvement on the one line at a time on hitting 'return'. So QC's EM did one response per char and when he installed it at U of C Berkeley the sysadmins there who had visual displays rejected it as too expensive on their multi-user UNIX CPU. It was Bill Joy (BJ) the Pascal Compiler BSD (Berkeley Software Distribution) guy who showed GC around and eventually extended GC's EM into EX and then into EX's 'open buffer command' Vi with the facility of 'raw mode' recently made available in DEC Virtual Terminal devices. Until then teletypes were truly Dumb Terminals as IBMers called them.

I'll stop here to not spoil it for those that might want to browse the QMCL.ac.uk link for themselves.

Side Note: During QC's stint at Berkeley the hot thing going then, he says, was the creation / development of Ingress. I think IBM had not long before released the definition of RDBMS into the public domain. Remember, Ingress was the mother of Postgress, the Auntie of Sybase, the God Mother of Informix and Grand Mother of MS SQL Server ...

The other minor historical is that BSD (Berkeley Software Distribution with the Regents U o C Copyright Notice and all) as a distribution of UNIX was pretty much predated in the Software Distribution by Bill Joy of his Pascal Compiler. UNIX (more or less mainly him again) came later under his 'Frienzied' PhD years there adding plenty core tools into BSD UNIX including building the TCP/IP stack from scratch (a first ever) after throwing out the 'IMPS' buggy and RFC-outdated variant that came with AT&T UNIX.

There's a lot more that was happening in frenzied fashion at Berkerley. Another big intersection was Bill Joy with the goings on at MIT that eventually got James Gosling to join them years later at SUN Microsystems (R.I.P), to eventually put together the ultimate byte code interpreter Mother of all interpreters we now call JVM Java. Despite all the Lore one hears, Emacs as we know it might have never come to being were it not for that same JG.

Last nugget (could'nt resist): That UK Amiga was also the basis of all the ARM architecture design that rules the embedded and SoC worlds today.

MKhomo
  • 462
  • 3
  • 8