Firstly, "background" has a special meaning under Unix/Linux. It means a program running without being waited on by the shell prompt where the user types. I think you mean, "What is going on internally?"
The simplest explanation doesn't involve a GUI desktop. Imagine you are working at the console (the monitor and keyboard directly connected to the Unix/Linux box). In that case, you might see a plain, 25x80 character mode screen instead of some GUI desktop. You can see that screen when a PC turns on, or when the GRUB bootloader is running, or when the Linux kernel is starting up. You can also jump into console mode using some keystroke sequence that I can't remember offhand.
Before you type "cat," there is already a program running. It's the shell, usually called "bash" or "ksh." The shell is smart about terminals/keyboards. It can read keystrokes and write to the terminal. It uses the terminfo or termcap databases supplied with Linux so that many types of terminal can be used. Compare that with DOS, which only supports PC consoles. Most Linux boxes have PC consoles (or no console), but technically anything from a VT100 to a WYSE terminal and beyond is possible. Linux thinks in terms of terminals rather than monitors, because in the past, the screen and keyboard were molded together into the one unit. Only the very earliest PC's were like that. Most PC's now have separate keyboards and monitors.
Most Linux programs, including shells, can send or receive bytes through three standard outlets. They're called "stdin" (standard input), "stdout" (standard output) and "stderr" (standard error). They're basic programmer concepts from the C language. When bytes are read or written to one of these, the Linux kernel sends the bytes to the hardware or to another program. For hardware, a special file called a device file is used. There's one device file per physical terminal (monitor) attached.
For the shell, outlets stdin, stdout and stderr are connected to the terminal device. The user hits a key, the shell reads it from stdin, and the shell prints it to stdout so you can see it's been hit. So a shell is pretty close to DOS, except there's a device file and the kernel between it and the monitor. Under DOS there's nothing between except a trivial driver.
When you type "cat ...", the shell starts up a new program (the concatenate program). It waits for that program to finish, and does nothing until then. That new program has the same stdin, stdout and stderr as the shell. The first thing cat does is look at the filename passed to it. It opens a new inlet (like stdin) and starts reading the file. It sends the bytes of content read to its normal stdout, which is the same device and terminal as the shell uses. When cat finishes, it just dies neatly, and the shell resumes and waits for more user input. The illusion is that the shell and cat are somehow integrated. They're not.
You can, with a little planning, run cat 10 times in parallel, and the output from all 10 will appear on the screen mixed together. All 10 are writing to the same device. The "wall" command takes advantage of this.
If you run your shell inside a terminal emulator on a GUI desktop, like xterm under GNOME, then the explanation's the same, except that the terminal emulator isn't a "real" terminal like a physical console. It's a program pretending to be a terminal.
Editor's note: You can read more about the "cat" command in this expert response from Ken Milberg.
This was first published in August 2004