Path: utzoo!attcan!uunet!wuarchive!cs.utexas.edu!tut.cis.ohio-state.edu!purdue!haven!ncifcrf!nlm-mcs!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.questions
Subject: Re: stupid unix questions
Message-ID: <12757@smoke.BRL.MIL>
Date: 2 May 90 05:38:40 GMT
References: <15758@phoenix.Princeton.EDU> <1990Apr29.222031.1043@diku.dk> <3653@castle.ed.ac.uk> <1990Apr30.053057.2943@smsc.sony.com> <15849@phoenix.Princeton.EDU>
Organization: U.S. Army Ballistic Research Laboratory
Lines: 18

In article <15849@phoenix.Princeton.EDU> pmullman@phoenix.Princeton.EDU (Peter M. Ullman) writes:
>If I find later I have made a mistake, I can snarf the correct parts
>off the screen, and just retype the incorrect parts.

This sort of thing is what caused us to make the BRL Bourne shell's
"history" command display the command history without extra cruft on
the beginnings of the lines, unlike csh, and also to make the "whatis"
builtin display its output in a form suitable for re-input to the
shell, unlike AT&T's Bourne shell's "type" builtin.  Similar thought
went into the order of execution of the $ENV file vs. .profile,
non-use of $ENV by scripts, and so forth, all different from the way
ksh does these things.

It helps if you're accustomed to a nice interactive terminal like the
AT&T 630 where cut-and-paste operations on the text display are quite
natural, so that you really do use them frequently.  In sicker
environments, the advantages of clean user interfaces are not so
evident.