# To unbundle, run this file
echo p0
sed 's/.//' >p0 <<'//GO.SYSIN DD p0'
-.RP
-.TM "79-1274-xx 79-1273-yy" 39199 39199-11
-....ND June 18, 1976
-....TM "76-1274-6 76-1273-5" 39199 39199-11
-.TL
-LEARN \(em Computer-Aided Instruction on UNIX
-.br
-(Second Edition)
-.AU "MH 2C-518" 6021
-Brian W. Kernighan
-.AU "MH 2C-569" 6377
-Michael E. Lesk
-.AI
-.MH
-.OK
-CAI
-.AB
-.PP
-This paper describes the
-second version of the
-.I
-learn
-.R
-program for interpreting CAI
-scripts on
-the
-.UX 
-operating system,
-and a set of scripts that provide a computerized introduction
-to the system.
-.PP
-Six current scripts cover basic commands and file
-handling, the editor, additional file handling commands, the
-.I
-eqn
-.R
-program for mathematical
-typing,
-the ``\-ms'' package of formatting macros,
-and an introduction to the C programming language.
-These scripts now include a total of
-about 530 lessons.
-.PP
-Many users from a wide variety of backgrounds have used
-.I learn
-to acquire basic UNIX skills.
-Most usage involves the first two scripts,
-an introduction to
-.UX
-files and commands, and
-the
-.UX
-editor.
-.PP
-The second version of
-.I learn
-is about four times faster than the previous one
-in CPU utilization,
-and much faster in perceived time
-because of better overlap of computing and printing.
-It also requires less file space than the first version.
-Many of the lessons have been revised;
-new material has been added to reflect changes
-and enhancements in 
-.UX
-itself.
-Script-writing is also easier
-because of revisions to the script language.
-.AE
-.CS 11 2 13 4 0 0
//GO.SYSIN DD p0
echo p2
sed 's/.//' >p2 <<'//GO.SYSIN DD p2'
-.NH
-Educational Assumptions and Design.
-.PP
-First, the way to teach people how to do something
-is to have them do it.  Scripts should
-not contain long pieces of explanation; they should
-instead frequently ask the student to do some task.
-So teaching is always by example: the typical
-script fragment shows a small example of some
-technique and then asks the
-user to either repeat that example or
-produce a variation on it.
-All are intended to be easy enough that most students will get most questions
-right, reinforcing the desired behavior.
-.PP
-Most lessons fall into one of three types.
-The simplest presents a lesson and asks for a yes or no
-answer to a question.
-The student is given a chance to experiment before replying.
-The script checks for the correct reply.
-Problems of this form are sparingly used.
-.PP
-The second type asks for a word or number as an answer.
-For example a lesson on files might say
-.IP
-.I
-How many files are there in the current directory?
-Type ``answer N'', where N is the number of files.
-.R
-.LP
-The student is expected to respond (perhaps after experimenting) with
-.LP
-.I
-	answer 17
-.R
-.LP
-or whatever.
-Surprisingly often, however, the idea of a substitutable argument
-(i.e., replacing
-.I
-N
-.R
-by
-17)
-is difficult for non-programmer students,
-so the first few such lessons need real care.
-.PP
-The third type of lesson is open-ended \(em
-a task is set for the student,
-appropriate parts of the input or output are monitored,
-and the student types 
-.ul
-ready
-when the task is done.
-Figure 1 shows a sample dialog that illustrates the last of these, using two
-lessons about the
-.I cat
-(concatenate, i.e., print) command taken
-from early in the script that teaches
-file handling.
-Most
-.I learn
-lessons are of this form.
-.KF
-.TS
-box, center;
-c.
-T{
-Figure 1:  Sample dialog from basic files script
-.sp
-(Student responses
-in italics; `$' is the prompt)
-.nf
-.sp
-A file can be printed on your terminal
-by using the "cat" command.  Just say
-"cat file" where "file" is the file name.
-For example, there is a file named
-"food" in this directory.  List it
-by saying "cat food"; then type "ready".
-$ \fIcat food\fR
-  this is the file
-  named food.
-$ \fIready\fR
-
-Good.  Lesson 3.3a (1)
-
-Of course, you can print any file with "cat".
-In particular, it is common to first use
-"ls" to find the name of a file and then "cat"
-to print it.  Note the difference between
-"ls", which tells you the name of the file,
-and "cat", which tells you the contents.
-One file in the current directory is named for
-a President.  Print the file, then type "ready".
-$ \fIcat President\fR
-cat: can't open President
-$ \fIready\fR
-
-Sorry, that's not right.  Do you want to try again? \fIyes\fR
-Try the problem again.
-$ \fIls\fR
-\&.ocopy
-X1
-roosevelt
-$ \fIcat roosevelt\fR
-  this file is named roosevelt
-  and contains three lines of
-  text.
-$ \fIready\fR
-
-Good.  Lesson 3.3b (0)
-
-The "cat" command can also print several files
-at once.  In fact, it is named "cat" as an abbreviation
-for "concatenate"....
-.fi
-T}
-.TE
-.sp
-.KE
-.PP
-After each correct response the computer congratulates
-the student and indicates the lesson number that
-has just been completed, permitting the student
-to restart the script after that lesson.
-If the answer is wrong, the student
-is offered a chance to repeat the lesson.
-The ``speed'' rating of the student (explained in
-section 5) is given after the lesson number when the lesson is completed successfully; it is
-printed only for the aid of script authors checking
-out possible errors in the lessons.
-.br
-.PP
-It is assumed that there is no foolproof way
-to determine if the student truly ``understands''
-what he or she is doing;
-accordingly,
-the current
-.I
-learn
-.R
-scripts
-only measure performance, not comprehension.
-If the student can perform a given task, that is deemed to be ``learning.''
-.[
-skinner teaching 1961
-.]
-.PP
-The main point of using the computer is that what the student
-does is checked for correctness immediately.
-Unlike many CAI scripts, however, these scripts provide
-few facilities for dealing with wrong answers.
-In practice, if most of the answers are not right the script is
-a failure; the universal solution to student error is to provide
-a new, easier script.
-Anticipating possible wrong answers is an endless job, and it is really
-easier as well as better to provide a simpler script.
-.PP
-Along with this goes the assumption that
-anything can be taught to anybody if it can
-be broken into sufficiently small pieces.  Anything
-not absorbed in a single chunk is just subdivided.
-.PP
-To avoid boring the faster students,
-however,
-an effort is made in the files and editor scripts to provide
-three tracks of different difficulty.
-The fastest sequence of lessons
-is aimed at roughly the bulk and speed of a typical tutorial
-manual and should be adequate for review and for
-well-prepared students.
-The next track is intended for most users and is roughly
-twice as long.  Typically, for example, the fast track
-might present an idea and ask for a variation on the
-example shown; the normal track will first
-ask the student to repeat the example that was shown
-before attempting a variation.
-The third and slowest track, which is often
-three or four times the length of the fast track,
-is intended to be adequate for anyone.
-(The lessons of Figure 1 are from the third track.)
-The multiple tracks also mean that a student repeating a course is unlikely
-to hit the same series of lessons; this makes it profitable for a shaky
-user to back up and try again, and many students have done so.
-.PP
-The tracks are not completely distinct, however.
-Depending on the number of correct answers the student has given for the
-last few lessons, the program may switch tracks.
-The driver is actually capable of following
-an arbitrary directed graph of lesson sequences, as discussed in section 5.
-Some more structured arrangement, however, is used in all current scripts
-to aid the script writer in organizing the material into lessons.
-It is sufficiently difficult
-to write lessons
-that the three-track theory
-is not followed very closely
-except in
-the files and editor scripts.
-Accordingly,
-in some cases, the fast track is produced merely by skipping
-lessons from the slower track.
-In others, there is essentially only one track.
-.PP
-The main reason for using the
-.I
-learn
-.R
-program rather than
-simply writing the same material as a workbook
-is not the selection of tracks, but
-actual hands-on experience.
-Learning by doing
-is much more effective
-than pencil and paper exercises.
-.PP
-.I Learn
-also provides a mechanical check on performance.
-The first version in fact would not let
-the student proceed unless it
-received correct answers to the questions
-it set and it would not tell a student the right answer.
-This somewhat Draconian approach has been moderated
-in version 2.
-Lessons are sometimes badly worded or even just plain wrong;
-in such cases,
-the student has no recourse.
-But if a student is simply unable to complete one lesson,
-that should not prevent access to the rest.
-Accordingly, the current version of
-.I learn
-allows the student to skip
-a lesson that he cannot pass;
-a ``no'' answer to the ``Do you want to try again?''
-question in Figure 1 will pass to the next lesson.
-It is still true that 
-.I learn
-will not tell the student the right answer.
-.PP
-Of course, there are valid objections to the
-assumptions above.
-In particular, some students may object to
-not understanding
-what they are doing;
-and the procedure of smashing everything into small pieces may provoke
-the retort ``you can't cross a ditch in two jumps.''
-Since writing CAI scripts is considerably
-more tedious than ordinary manuals, however, it is safe
-to assume that there will always be alternatives to the
-scripts as a way of learning.
-In fact, for a reference manual of 3 or 4 pages it would
-not be surprising to have a tutorial manual of 20 pages
-and a (multi-track) script of 100 pages.  Thus the reference manual
-will exist long before the scripts.
//GO.SYSIN DD p2
echo p3
sed 's/.//' >p3 <<'//GO.SYSIN DD p3'
-.NH
-Scripts.
-.PP
-As mentioned above, the present scripts try
-at most
-to follow a three-track theory.  Thus little
-of the potential complexity of the possible directed graph
-is employed, since
-care must be taken in lesson construction to see
-that every necessary fact is presented in
-every possible path through the units.  In addition,
-it is desirable that every unit have alternate successors
-to deal with student errors.
-.PP
-In most existing courses, the first few lessons
-are devoted to checking prerequisites.  For example,
-before the student is allowed to proceed through the editor
-script the script verifies that the student understands files
-and is able to type.
-It is felt that the sooner lack of student preparation
-is detected, the easier it will be on the student.
-Anyone proceeding through the scripts
-should be getting mostly correct answers; otherwise, the
-system will be unsatisfactory both because the wrong
-habits are being learned and because the
-scripts make little effort to deal with wrong answers.
-Unprepared students should not be encouraged
-to continue with scripts.
-.PP
-There are some preliminary items which the student must
-know before any scripts can be tried.  In particular,
-the student must know how to connect to
-a
-.UX
-system,
-set the terminal properly,
-log in,
-and execute simple commands (e.g.,
-.ul
-learn
-itself).
-In addition, the character erase and line kill conventions
-(# and @) should be known.
-It is hard to see how this much could be taught by
-computer-aided instruction, since a student who
-does not know these basic skills will not be able
-to run the learning program.
-A brief description on paper is provided (see Appendix A), although
-assistance will be needed for the first few
-minutes.  This assistance, however, need not be highly skilled.
-.PP
-The first script in the current set deals with files.  It assumes
-the basic knowledge above and teaches the student about
-the
-.I ls ,
-.I cat ,
-.I mv ,
-.I rm ,
-.I cp
-and
-.I diff
-commands.
-.tr ~
-It also deals with the abbreviation characters *, ?, and [\ ]
-in file names.
-It does not cover pipes or I/O redirection,
-nor does it present the many options
-on the
-.ul
-ls
-command.
-.PP
-This script contains 31 lessons
-in the fast track;
-two are
-intended as prerequisite checks,
-seven are review exercises.
-There are a total of 75 lessons in all three tracks,
-and the instructional passages typed at the student
-to begin each lesson total 4,476 words.  The average
-lesson thus begins with a 60-word message.
-In general, the fast track lessons have somewhat longer
-introductions, and the slow tracks somewhat shorter ones.
-The longest message is 144 words and the shortest 14.
-.PP
-The second script trains students in the use
-of the
-.UX
-context editor
-.I ed ,
-a sophisticated editor
-using regular expressions for searching.
-.[
-ritchie thompson unix  seventh edition 1978
-%O See section \f2ed\f1 (I).
-.]
-All editor
-features except encryption, mark names and `;' in addressing
-are covered.
-The fast track contains 2 prerequisite checks,
-93 lessons, and a review lesson.
-It is supplemented by 146 additional lessons in other tracks.
-.PP
-A comparison of sizes may be of interest.  The
-.ul
-ed
-description
-in the reference manual is 2,572 words long.  The
-.ul
-ed
-tutorial
-.[
-kernighan editor tutorial 1974
-.]
-is 6,138 words long.  
-The fast track through
-the
-.ul
-ed
-script is 7,407 words of explanatory messages, and the
-total
-.ul
-ed
-script, 242 lessons, 
-has 15,615 words.
-The average
-.ul
-ed
-lesson is thus also about 60 words; the largest
-is 171 words and the smallest 10.
-The
-original
-.ul
-ed
-script represents about three man-weeks of effort.
-.PP
-The advanced file handling script deals with
-.ul
-ls
-options,
-I/O diversion, pipes, and supporting programs like
-.I pr ,
-.I wc ,
-.I tail ,
-.I spell
-and
-.I grep .
-(The basic file handling script is a prerequisite.)
-It is not as refined as the first two scripts;
-this is reflected at least partly in the fact that
-it provides much less of a full three-track sequence
-than they do.
-On the other hand,
-since it is perceived as ``advanced,''
-it is hoped that the student will have somewhat
-more sophistication
-and be better able to cope with it at a reasonably
-high level of performance.
-.PP
-A fourth script covers the
-.ul
-eqn
-language for typing mathematics.
-This script must be run on a terminal capable of printing
-mathematics, for instance the DASI 300 and similar Diablo-based
-terminals, or the nearly extinct Model 37 teletype.
-Again, this script is relatively short of tracks:
-of 76 lessons, only 17 are in the second track and 2
-in the third track.
-Most of these provide additional practice for students
-who are having trouble in the first track.
-.PP
-The
-.I \-ms
-script for formatting macros
-is a short one-track only script.
-The macro package it describes is no longer the standard,
-so this script will undoubtedly be superseded
-in the future.
-Furthermore, the linear style of a single learn script is somewhat
-inappropriate for the macros, since the macro package is composed of many
-independent features, and few users need all of them.
-It would be better to have a selection of short lesson
-sequences dealing with the features independently.
-.PP
-The script on C is in a state of transition.
-It was originally designed to follow
-a tutorial on C,
-but that document has since become obsolete.
-The current script has been partially converted
-to follow the order of presentation in
-.ul
-The C Programming Language,
-.[
-ritchie kernighan programming 1978 prentice hall
-.]
-but this job is not complete.
-The C script was never intended to teach C;
-rather it is supposed to be a series of exercises
-for which the computer provides checking and
-(upon success) a suggested solution.
-.PP
-This combination of scripts covers much of the material which any
-.UX
-user
-will need to know
-to make effective use of the system.
-With enlargement of the advanced files
-course to include more on the command interpreter, there
-will be a relatively complete introduction to
-.UX
-available via
-.ul
-learn.
-Although we make no pretense that 
-.ul
-learn
-will replace other instructional materials,
-it should provide a useful supplement to existing tutorials and reference manuals.
//GO.SYSIN DD p3
echo p4
sed 's/.//' >p4 <<'//GO.SYSIN DD p4'
-.NH
-Experience with Students.
-.PP
-.I
-Learn
-.R
-has been installed on
-many different 
-.UX
-systems.
-Most of the usage is on the first two scripts, so these
-are more thoroughly debugged and polished.
-As a (random) sample of user experience,
-the
-.I learn
-program has been used at Bell Labs at Indian Hill
-for 10,500 lessons in a four month period.
-About 3600 of these are in the files script,
-4100 in the editor,
-and 1400 in advanced files.
-The passing rate is about 80%,
-that is, about 4 lessons are passed for every one
-failed.
-There have been 86 distinct users of the files script,
-and 58 of the editor.
-On our system at Murray Hill, there have been nearly 2000 lessons
-over two weeks that include
-Christmas and New Year.
-Users have ranged in age from six up.
-.PP
-It is difficult to characterize typical sessions with the
-scripts;
-many instances exist of someone doing one or two lessons
-and then logging out, as do instances of someone pausing
-in a script for twenty minutes or more.
-In the earlier version of
-.I learn ,
-the average session in the files course took 32 minutes and covered
-23 lessons.
-The distribution is quite
-broad and skewed, however; the longest session was
-130 minutes and there were five sessions shorter than
-five minutes.
-The average lesson took about 80 seconds.
-These numbers are roughly typical for non-programmers;
-a
-.UX
-expert can do the scripts at approximately 30 seconds
-per lesson, most of which is the system printing.
-.PP
-At present working through a section of the middle of the files
-script took about 1.4 seconds of processor time per lesson,
-and a system expert typing quickly took 15 seconds of real time per lesson.
-A novice would probably take at least a minute.
-Thus a UNIX system could support ten students working simultaneously
-with some spare capacity.
//GO.SYSIN DD p4
echo p5
sed 's/.//' >p5 <<'//GO.SYSIN DD p5'
-.NH
-The Script Interpreter.
-.PP
-The
-.I
-learn
-.R
-program itself merely interprets scripts.  It provides
-facilities for the script writer to capture student
-responses and their effects, and simplifies the job
-of passing control to and recovering control from the student.
-This section describes the operation and
-usage of the driver program,
-and indicates what is
-required to produce a new script.
-Readers only interested in
-the existing scripts may skip this section.
-.PP
-The file structure used by
-.I learn
-is shown in Figure 2.
-There is one parent directory (named \f2lib\f1\^) containing the script data.
-Within this directory are subdirectories, one for each
-subject in which a course is available,
-one for logging (named
-.I log ),
-and one in which user sub-directories
-are created (named
-.I play ).
-The subject directory contains master copies of all lessons,
-plus any supporting material for that subject.
-In a given subdirectory,
-each lesson is a single text file.
-Lessons are usually named systematically;
-the file that contains lesson
-.I n
-is called
-.I Ln .
-.br
-.KF
-.sp
-.TS
-center, box;
-c s s s
-l l l l.
-Figure 2:  Directory structure for \fIlearn\fR
-.sp
-.nf
-lib
-.if t .sp .5
-	play
-		student1
-			files for student1...
-		student2
-			files for student2...
-.if t .sp .5
-	files
-		L0.1a	lessons for files course
-		L0.1b
-		...
-.if t .sp .5
-	editor
-		...
-.if t .sp .5
-	(other courses)
-.if t .sp .5
-	log
-.TE
-.sp
-.KE
-.PP
-When
-.I
-learn
-.R
-is executed, it makes a private directory
-for the user to work in,
-within the
-.I
-learn
-.R
-portion of the file system.
-A fresh copy of all the files used in each lesson
-(mostly data for the student to operate upon) is made each
-time a student starts a lesson,
-so the script writer may assume that everything
-is reinitialized each time a lesson is entered.
-The student directory is deleted after each session; any permanent records
-must be kept elsewhere.
-.PP
-The script writer must provide certain basic items
-in each
-lesson:
-.IP (1)
-the text of the lesson;
-.IP (2)
-the set-up commands to be executed before the user gets control;
-.IP (3)
-the data, if any, which the user is supposed to edit, transform, or otherwise
-process;
-.IP (4)
-the evaluating commands to be executed after the user
-has finished the lesson, to decide whether the answer is right;
-and
-.IP (5)
-a list of possible successor lessons.
-.LP
-.I
-Learn
-.R
-tries to minimize the work
-of bookkeeping and installation, so
-that most of the effort involved in
-script production is in planning lessons,
-writing tutorial paragraphs,
-and coding tests of student performance.
-.PP
-The basic sequence of events is
-as follows.
-First,
-.I learn
-creates the working directory.
-Then, for each lesson,
-.I learn
-reads the script for the lesson and processes
-it a line at a time.
-The lines in the script are:
-(1) commands to the script interpreter
-to print something, to create a files,
-to test something, etc.;
-(2) text to be printed or put in a file;
-(3) other lines, which are sent to
-the shell to be executed.
-One line in each lesson turns control over
-to the user;
-the user can run any 
-.UX 
-commands.
-The user mode terminates when the user
-types 
-.I yes ,
-.I no ,
-.I ready ,
-or
-.I answer .
-At this point, the user's work is tested;
-if the lesson is passed,
-a new lesson is selected, and if not
-the old one is repeated.
-.PP
-Let us illustrate this with the script
-for the second lesson of Figure 1;
-this is shown in Figure 3.
-.KF
-.sp
-.TS
-center, box;
-c.
-T{
-Figure 3:  Sample Lesson
-.sp
-.nf
-#print
-Of course, you can print any file with "cat".
-In particular, it is common to first use
-"ls" to find the name of a file and then "cat"
-to print it.  Note the difference between
-"ls", which tells you the name of the files,
-and "cat", which tells you the contents.
-One file in the current directory is named for
-a President.  Print the file, then type "ready".
-#create roosevelt
-  this file is named roosevelt
-  and contains three lines of
-  text.
-#copyout
-#user
-#uncopyout
-tail \-3 .ocopy >X1
-#cmp X1 roosevelt
-#log
-#next
-3.2b 2
-.fi
-T}
-.TE
-.sp
-.KE
-.LP
-Lines which begin with
-# are commands to the
-.I  learn 
-script interpreter.
-For example,
-.LP
-.ul
-	#print
-.LP
-causes printing of any text that follows,
-up to the next line that begins with a sharp.
-.LP
-.ul
-	#print file
-.LP
-prints the contents of
-.I file ;
-it
-is the same as
-.ul
-cat file 
-but has
-less overhead.
-Both forms of
-.I #print
-have the added property that if a lesson is failed,
-the
-.ul
-#print
-will not be executed the second time through;
-this avoids annoying the student by repeating the preamble
-to a lesson.
-.LP
-.ul
-	#create filename
-.LP
-creates a file of the specified name,
-and copies any subsequent text up to a
-# to the file.
-This is used for creating and initializing working files
-and reference data for the lessons.
-.LP
-.ul
-	#user
-.LP
-gives control to the student;
-each line he or she types is passed to the shell
-for execution.
-The
-.I #user
-mode
-is terminated when the student types one of
-.I yes ,
-.I no ,
-.I ready 
-or
-.I answer .
-At that time, the driver
-resumes interpretation of the script.
-.LP
-.ul
-	#copyin
-.br
-.ul
-	#uncopyin
-.LP
-Anything the student types between these
-commands is copied onto a file
-called
-.ul
-\&.copy.
-This lets the script writer interrogate the student's
-responses upon regaining control.
-.LP
-.ul
-	#copyout
-.br
-.ul
-	#uncopyout
-.LP
-Between these commands, any material typed at the student
-by any program
-is copied to the file
-.ul
-\&.ocopy.
-This lets the script writer interrogate the
-effect of what the student typed, 
-which true believers in the performance theory of learning
-usually
-prefer to the student's actual input.
-.LP
-.ul
-	#pipe
-.br
-.ul
-	#unpipe
-.LP
-Normally the student input and the script commands
-are fed to the
-.UX
-command interpreter (the ``shell'') one line at a time. This won't do
-if, for example, a sequence of editor commands
-is provided,
-since the input to the editor must be handed to the editor,
-not to the shell.
-Accordingly, the material between 
-.ul
-#pipe
-and
-.ul
-#unpipe
-commands
-is fed
-continuously through a pipe so that such sequences
-work.
-If
-.ul
-copyout
-is also desired
-the
-.ul
-copyout
-brackets must include
-the
-.ul
-pipe
-brackets.
-.PP
-There are several commands for setting status
-after the student has attempted the lesson.
-.LP
-.ul
-	#cmp file1 file2
-.LP
-is an in-line implementation of
-.I cmp ,
-which compares two files for identity.
-.LP
-.ul
-	#match stuff
-.LP
-The last line of the student's input
-is compared to
-.I stuff ,
-and the success or fail status is set
-according to it.
-Extraneous things like the word
-.I answer
-are stripped before the comparison is made.
-There may be several 
-.I #match
-lines;
-this provides a convenient mechanism for handling multiple
-``right'' answers.
-Any text up to a
-# on subsequent lines after a successful
-.I #match
-is printed; 
-this is illustrated in Figure 4, another sample lesson.
-.br
-.KF
-.sp
-.TS
-center, box;
-c.
-T{
-Figure 4:  Another Sample Lesson
-.sp
-.nf
-#print
-What command will move the current line
-to the end of the file?  Type 
-"answer COMMAND", where COMMAND is the command.
-#copyin
-#user
-#uncopyin
-#match m$
-#match .m$
-"m$" is easier.
-#log
-#next
-63.1d 10
-T}
-.TE
-.sp
-.KE
-.LP
-.ul
-	#bad stuff
-.LP
-This is similar to
-.I #match ,
-except that it corresponds to specific failure answers;
-this can be used to produce hints for particular wrong answers
-that have been anticipated by the script writer.
-.LP
-.ul
-	#succeed
-.br
-.ul
-	#fail
-.LP
-print a message
-upon success or failure
-(as determined by some previous mechanism).
-.PP
-When the student types
-one of the ``commands''
-.I yes ,
-.I no ,
-.I ready ,
-or
-.I answer ,
-the driver terminates the
-.I #user
-command,
-and evaluation of the student's work can begin.
-This can be done either by
-the built-in commands above, such as
-.I #match
-and
-.I #cmp ,
-or by status returned by normal
-.UX 
-commands, typically
-.I grep
-and
-.I test .
-The last command
-should return status true
-(0) if the task was done successfully and
-false (non-zero) otherwise;
-this status return tells the driver
-whether or not the student
-has successfully passed the lesson.
-.PP
-Performance can be logged:
-.LP
-.ul
-	#log file
-.LP
-writes the date, lesson, user name and speed rating, and
-a success/failure indication on
-.ul
-file.
-The command
-.LP
-.ul
-	#log
-.LP
-by itself writes the logging information
-in the logging directory
-within the
-.I learn
-hierarchy,
-and is the normal form.
-.LP
-.ul
-	#next
-.LP
-is followed by a few lines, each with a successor
-lesson name and an optional speed rating on it.
-A typical set might read
-.LP
-.nf
-	25.1a   10
-	25.2a   5
-	25.3a   2
-.fi
-.LP
-indicating that unit 25.1a is a suitable follow-on lesson
-for students with
-a speed rating of 10 units,
-25.2a for student with speed near 5,
-and 25.3a for speed near 2.
-Speed ratings are maintained for
-each session with a student; the
-rating is increased by one each tiee
-the student gets a lesson right and decreased
-by four each
-time the student gets a lesson wrong.
-Thus the driver tries to maintain a devel such
-that the users get 80% right answers.
-The maximum rating is limited to 10 afd the minimum to 0.
-The initial rating is zero unless the studeft
-specifies a differeft rating when starting
-a session.
-.PP
-If the student passes a lesson,
-a new lesson is sedected and the process repeats.
-If the student fails, a false status is returned
-and the program
-reverts to the previous lesson and tries
-another alternative.
-If it can not find another alternative, it skips forward
-a lesson.
-.I bye ,
-bye,
-which causes a graceful exit
-from the 
-.ul
-learn
-system.  Hanging up is the usual novice's way out.
-.PP
-The lessons may form an arbitrary directed graph,
-although the present program imposes a limitation on cycles in that
-it will not present a lesson twice in the
-same session.
-If the student is unable to answer one of the exercises
-correctly, the driver searches for a previous lesson
-with a set of alternatives as successors
-(following the
-.I #next
-line).
-From the previous lesson with alternatives one route was taken
-earlier; the program simply tries a different one.
-.PP
-It is perfectly possible
-to write sophisticated scripts that evaluate
-the student's speed of response, or try to estimate the
-elegance of the answer, or provide detailed
-analysis of wrong answers.
-Lesson writing is so tedious already, however, that most
-of these abilities are likely to go unused.
-.PP
-The driver program depends heavily on features
-of
-.UX
-that are not available on many other operating systems.
-These include
-the ease of manipulating files and directories,
-file redirection,
-the ability to use the command interpreter
-as just another program (even in a pipeline),
-command status testing and branching,
-the ability to catch signals like interrupts,
-and of course
-the pipeline mechanism itself.
-Although some parts of 
-.ul
-learn
-might be transferable to other systems,
-some generality will probably be lost.
-.PP
-A bit of history:
-The first version of
-.I learn
-had fewer built-in words
-in the driver program,
-and made more use of the
-facilities of
-.UX .
-For example,
-file comparison was done by creating a
-.I cmp
-process,
-rather than comparing the two files within
-.I learn .
-Lessons were not stored as text files,
-but as archives.
-There was no concept of the in-line document;
-even 
-.I #print
-had to be followed by a file name.
-Thus the initialization for each lesson
-was to extract the archive into the working directory
-(typically 4-8 files),
-then 
-.I #print
-the lesson text.
-.PP
-The combination of such things made
-.I learn
-slower.
-The new version is about 4 or 5 times faster.
-Furthermore, it appears even faster to the user
-because in a typical lesson,
-the printing of the message comes first,
-and file setup with
-.I #create
-can be overlapped with the printng,
-so that when the program
-finishes printing,
-it is really ready for the user
-to type at it.
-.PP
-It is also a great advantage to the script maintainer
-that lessons are now just ordinary text files.
-They can be edited without any difficulty,
-and  
-.UX
-text manipulation tools can be applied
-to them.
-The result has been that
-there is much less resistance
-to going in and fixing substandard lessons.
//GO.SYSIN DD p5
echo p6
sed 's/.//' >p6 <<'//GO.SYSIN DD p6'
-.NH
-Conclusions
-.PP
-The following observations can be made about
-secretaries, typists, and
-other non-programmers who have used
-.I learn :
-.IP (a)
-A novice must have assistance with the mechanics
-of communicating with the computer to get through to
-the first lesson or two;
-once the first few lessons are passed people can proceed
-on their own.
-.IP (b)
-The terminology used in the first few lessons
-is obscure to those inexperienced with computers.
-It would help if there were a low level
-reference card for
-.UX
-to supplement the existing
-programmer oriented bulky manual and bulky reference card.
-.IP (c)
-The concept of ``substitutable argument'' is hard
-to grasp, and requires help.
-.IP (d)
-They enjoy the system for the most part.
-Motivation matters a great deal, however.
-.LP
-It takes an hour or two for a novice to get through
-the script on file handling.
-The total time for a reasonably intelligent and motivated novice to proceed from ignorance
-to a reasonable ability to create new files and manipulate old ones
-seems to be a few days, with perhaps half of each day
-spent on the machine.
-.PP
-The normal way of proceeding has been to have students in the same
-room with someone who knows
-.UX
-and the scripts.
-Thus the student is not brought to a halt by
-difficult questions.  The burden on the counselor, however,
-is much lower than that on a teacher of a course.
-Ideally, the students should be encouraged to proceed with instruction
-immediately prior to their actual use of the computer.
-They should exercise the scripts on the same computer and the same
-kind of terminal that they will later use
-for their real work, and
-their first few jobs for the computer should be
-relatively easy ones.
-Also, both training and initial work should take place on days
-when the
-.UX
-hardware and software
-are working reliably.
-Rarely is all of this possible, but the closer one comes the better
-the result.
-For example, if it is known that the hardware is shaky one day, it is better
-to attempt to reschedule training for another one.  Students are very
-frustrated by machine downtime; when nothing is happening, it takes
-some sophistication and experience to distinguish
-an infinite loop, a slow but functioning program,
-a program waiting for the user, and a broken machine.*
-.FS
-* We have even known an expert programmer to decide the computer
-was broken when he had simply left his terminal in local mode.
-Novices have great difficulties with such problems.
-.FE
-.PP
-One disadvantage
-of training with
-.I
-learn
-.R
-is that students come to depend
-completely on the CAI system, and do not try
-to read manuals or use other learning aids.
-This is unfortunate, not only because of the increased
-demands for completeness and accuracy of the
-scripts, but because the scripts do not cover all of
-the
-.UX
-system.
-New users should have manuals (appropriate for their level) and
-read them; the scripts ought to be altered
-to recommend suitable documents and urge
-students to read them.
-.PP
-There are several other difficulties which are clearly evident.
-From the student's viewpoint,
-the most serious is that
-lessons still crop up which simply can't be passed.
-Sometimes this is due to poor explanations,
-but just as often it is some error in the lesson itself
-\(em a botched setup, a missing file,
-an invalid test for correctness,
-or some system facility that doesn't work on the local
-system in the same way it did on the development system.
-It takes knowledge and a certain healthy arrogance on the part of the user to recognize
-that the fault is not his or hers,
-but the script writer's.
-Permitting the student to get on with the next lesson
-regardless does alleviate this somewhat,
-and the logging facilities make it easy
-to watch for lessons that no one
-can pass,
-but it is still a problem.
-.PP
-The biggest problem with the previous
-.I learn
-was speed (or lack thereof) \(em
-it was often excruciatingly slow
-and made a significant drain on the system.
-The current version so far does not seem
-to have that difficulty,
-although some scripts,
-notably
-.I eqn ,
-are intrinsically slow.
-.I eqn ,
-for example,
-must do a lot of work even to print its introductions,
-let alone check the student responses,
-but delay is perceptible in all scripts
-from time to time.
-.PP
-Another potential problem is that it is possible
-to break
-.ul
-learn
-inadvertently, by pushing interrupt at the wrong time,
-or by removing critical files,
-or any number of similar slips.
-The defenses against such problems
-have steadily been improved, to the point
-where most students should not notice difficulties.
-Of course, it will always be possible to break
-.I
-learn
-.R
-maliciously, but this is not likely to be a problem.
-.PP
-One area is more fundamental \(em
-some
-.UX
-commands are sufficiently global in their effect
-that
-.ul
-learn
-currently
-does not allow them to be executed at all.
-The most obvious is
-.I cd ,
-which changes to another directory.
-The prospect of a student who is learning about directories
-inadvertently moving to some random directory
-and removing files has deterred us
-from even writing lessons on
-.I cd ,
-but ultimately lessons on such topics probably should be added.
//GO.SYSIN DD p6
echo p7
sed 's/.//' >p7 <<'//GO.SYSIN DD p7'
-.NH
-Acknowledgments
-.PP
-We are grateful to all those who have tried
-.ul
-learn,
-for we have benefited greatly from their
-suggestions and criticisms.
-In particular,
-M. E. Bittrich,
-J. L. Blue,
-S. I. Feldman,
-P. A. Fox,
-and
-M. J. McAlpin
-have provided substantial feedback.
-Conversations with E. Z. Rothkopf also provided many of the ideas in the system.
-We are also indebted to Don Jackowski
-for serving as a guinea pig for the second version,
-and to Tom Plum for his efforts to improve the C script.
-....SG \s-2MH\s0-1273/4-\s-2MEL/BWK\s0-unix
-.[
-$LIST$
-.]
//GO.SYSIN DD p7