Recording your session

A request $>filename starts writing a transcript of everything which shows on your screen to the file filename. All examples longer than a couple of lines were prepared this way. If the filename is missing then the currently opened transcript will be closed. The output is always appended to the given file, so that it is possible to open, close, and re-open the same file any number of times.

Because GEMDOS is not re-entrant it is not a very very good idea to perform an actual file write while processing a GEMDOS call. It is nearly certain you will crash your system. The safest course in such spots is to turn recording temporarily off. However, transcript output is buffered by default, so actual writes occur only when the buffer is flushed when full or because the file was closed. Therefore with proper care, one can empty the buffer prior to dangerous spots and even create a record of a GEMDOS call, provided it is not too wordy. A handy definition for a function key to do this is $>;$> (see the last section on function keys).

It is advisable not to write files to your hard drive, instead use a RAM drive or a dedicated floppy (which can be reformatted in case of disaster). Remember that a buggy program and the debugger can write anywhere. Over system file buffers and cached File Allocation Tables as well.

If you need all memory you can get it is possible to turn off transcript buffering with command line option -nb. But then you will have to be extremely careful about possible conflicts with GEMDOS.

NOTE! After $>file request your default command is $> and not the last command you were executing previously. It is possible to execute $> inadvertently by hitting Return or by making some mistake while typing the next line. This will close your transcript with obvious results. When something like thats happens, or when in doubt, issue another $>file.