UNIX for Advanced & Expert Users

A TTY terminal device is a character device that performs input and output on a character-by-character basis.

The communication between terminal devices and the programs that read and write to them is controlled by the TTY interface. Examples of TTY devices are ASCII terminal and modems.

Back in the old days, when Teletype devices and stand-alone terminals were connected by wires to the back of a shared computer or over a phone line that was connected to a modem that was connected by wires to the back of a shared computer, everyone knew how a terminal appeared as a character special file that supported the general terminal interfaces.

Most vendor man page set will have a termios man page (but the section it is in will vary). Chapter 11 of the Base Definitions volume of the current POSIX standard has more than a dozen pages describing the General Terminal Interface (GTI).

The extremely quick overview, is that any time you have a user typing on a keyboard to interactively enter input into a program and interactively looking at output produced by a program on a screen or typewriter-like device, you are likely using a tty device or pseudo-tty device that behaves mostly as specified by the POSIX GTI.

It is wise to log debug stuff to stderr, which by default is completely unbuffered. Just change 'printf(' to 'fprintf( stderr,'.

If speed is a focus, don't write bulk to unbuffered or line buffered FILE*'s like stderr, use a well buffered one, see man setvbuf(), some multiple of the disk page or packet size size like 65536 or 57600, less than the system write buffer or socket send buffer size, and fflush() only if necessary.

Calling exit() almost always flushes FILE*'s free of charge, but I had a primitive C compiler once that didn't.

---------- Post updated at 04:47 PM ---------- Previous update was at 04:46 PM ----------

You can use a tool like strace/truss/tusc to trace system calls and signals of the running process to a log file, and see what signals are doing what to your process.

It's also wise because it keeps your error messages separate from your data. If you're writing a PNG image to standard output, for instance, you don't want "Warning: Needed to flatten image" stuck randomly in the middle of that, you want that going where a human will read it or just nowhere. Writing to stderr lets you control it independently.

Good error handling makes for short debug times and happier production support. That is why stderr is always open and unbuffered at the start. Point it at a log file.