Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!watmath!clyde!bonnie!akgua!whuxlm!harpo!decvax!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.unix,net.unix-wizards Subject: Re: Re: Can something like Script be done in System V? Message-ID: <2354@sun.uucp> Date: Wed, 26-Jun-85 05:20:36 EDT Article-I.D.: sun.2354 Posted: Wed Jun 26 05:20:36 1985 Date-Received: Sat, 29-Jun-85 01:27:16 EDT References: <868@enea.UUCP> <11282@brl-tgr.ARPA> <2325@sun.uucp> <163@grpwre.UUCP> Organization: Sun Microsystems, Inc. Lines: 36 Xref: watmath net.unix:4903 net.unix-wizards:13658 > > there's not > > much point in running "vi" with its input coming from a program generating > > commands or from a file consisting of commands generated by a program. > > Guy Harris > > One point in running any program whose quality is to be assured, > including screen-oriented editors, with its input coming from a file is > in automating the testing process. A screen-oriented language-directed > editor in whose development I participated could not have been tested > in a timely way without using this technique. However, there may be some aspects of its behavior that can't be tested by running it from a file. (An example - an editor which can offload some of the low-level character processing to a smart terminal. Your front end tester will have to emulate the smart terminal - and even that may not be enough, if you're also trying to debug the terminal's behavior.) Also, that won't test its terminal mode setting/getting behavior (if it's a screen editor, it sets the terminal mode to something other than the default). If you want to *really* test that, or if you want to get a transcript of a session, something like "script" is the best choice - it eliminates one variable from the testing procedure (the program's input is at least coming from something it thinks is a terminal). Besides, these are all special cases. The point still remains that designing a screen editor so that it runs "just as well" with its input redirected to a pipe or file doesn't serve much purpose; if you want an editor that talks to programs or files, write an editor intended to be talked to by computer programs, not people. People are good at things that computers are very bad at and *vice versa*, so the quality of the user interface of an interactive tool should *not* be sacrificed in the name of "making it work with its input redirected". Guy Harris