$>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.