TTY.Specific 110 Bits

ITY streams have some additional characteristics not present in other stream types. They are also unable to send or receive certain octet values (Le., special control characters) unless some special bits are specified to the stream I/O procedures. The characteristics of TTY streams include:

• echo and line editing: Certain default actions take place when reading a line from a TIY, including the echo of typed characters back to the output side of the stream (Le., to the "screen"). Also, certain characters typed by the user are interpreted as line editing functions for correcting mistakes (e.g. delete or backspace). However, at times these defaults are not desired.

• interrupt characters: Certain character codes are interpreted in a special way by the operating system. When these characters are received by a ITY, they cause

"interrupts" to occur. For example, CTRL-C on the controlling terminal might abort the program doing the read. However, at times these interrupt characters must be turned off so that all characters may be read by the program.

• flow control: TTY streams often use distinguished character codes (e.g.,

XONIXOFF) to signal the writer that the reader is ready to accept more data. Flow control prevents the receiver's buffer from overflowing and is commonly used by interactive terminals, modems, and operating systems.

• transmission speed: Various TIY devices are capable of transmitting at different speeds (baud rates). The sender and receiver must agree on the rate.

When $text is read from a TTY stream in $line mode, and no special TIY -specific bits are set, reading occurs in units of lines, line editing characters are available to the user at the keyboard to correct mistakes on input, and the characters read are echoed to the output end of the stream.

When any of the buffering bits other than $line is used for TIY input, both line editing and the echoing of input to the output are disabled until a read is done from the 1TY stream in which

$line is specified.

When $text is written to a TTY stream in $line mode, eol characters are modified as necessary to cause the cursor to move to the beginning of the next line. Typically it is necessary to supply both a carriage return character and a linefeed character to the actual physical terminal. When output is done in a buffering mode other than $line, e.g., $unbuffered, no such manipulation of eol characters takes place. It is then the program's responsibility to ensure that the desired sequence of characters is sent. That sequence is available as the $stream field $unbufferedEol.

For example, under UNIX, the string eol contains the single character linefeed. If this alone were output to most terminals, the cursor would not move back to the first column of the screen; i.e.:

$writeStream($tty,"Hi" & eol & "Hi") would produce:

Hi Hi while either:

$writeStream($tty,"Hi" & eol & "Hi",$line) or:

$writeStream($tty,"Hi" & $tty.$unbufferedEol & "Hi") would produce:

Hi Hi

Aside from the side effects of echoing and eol manipulation associated with $line, the $line and

$unbuffered bits work for TIY's as they do for all other streams. The $fillBuffer and $packet buffering modes are of little use for TIY streams because such streams are unreliable when connected to a physical terminal line. However, these modes might be useful over a TTY stream that is connected to a parent process instead of a physical terminal.

System-specific interrupt characters and flow control characters introduce a slight complication into programming a TTY stream. By default, interrupt characters have a special effect and are

not passed to the program. The flow control characters are not available to the program, either for reading or writing.

Unless some special bits are set for TTY stream I/O, the programmer must be careful not to expect to read octets that correspond to interrupt or flow control characters or to write flow control characters and have them received at the other end of a ITY stream. Since these characters are usually non-printing characters, normal applications do not need to worry about this limitation. However, special applications such as screen editors and terminal emulators must take special action.

To vary these characteristics from the default, additional ctrlBits bits are provided for the stream input functions. The additional bits are:

• $nolnterrupt: Read characters that normally cause keyboard interrupts (e.g., CTRL-C) and return them as normal characters without causing the usual interrupt action. This mode is useful for implementing terminal emulators. It is set

automatically for $image reads. It is illegal in combination with $line.

• $noFlow: Turn off flow control and read the flow control characters as normal characters. This mode is useful for implementing multiwindow terminal emulators that wish to read XON/XOFF and apply them selectively to each window. It is set automatically for $image reads.

• $flow: Turn on flow control. If neither $flow or $noFlow is set, the stream module sets flow control in a device-dependent manner. In particular, for the controlling terminal, if neither bit is given, the flow control is set the way the user had it set up prior to running MAINSAIL.

These bits are ignored for non-TTY streams or in implementations where they cannot be supported.

For example, to read a character without echo and without waiting for an eol,

"$cReadStream($tty,$text!$unbuffered)" could be used, provided that $tty is not a half-duplex terminal. The program may want to echo the character it read. If it does not do so explicitly, the user does not see any echo.

The system procedure "ttycWrite(char)" functions similarly to

"$cWriteStream($tty ,char,$text!$line)". To cause char to be displayed immediately rather than waiting for an eol (full-duplex systems only), "$cWriteStream($tty,char,$text!$unbuffered)"

could be used instead. However, when $unbuffered is set, it is the responsibility of the

program to make sure that the sequence of characters $ tty .unbufferedEol is output at the end of a line~ This character sequence is not necessarily the same as the string constant eol.