Programs that run in a UNIX environment can be classified by their relationship to terminal devices and by their input\/output streams. They generally fall into one of three categories: software tools, daemons, and interactive user programs.<\/p>\n
A software tool is a program that<\/p>\n
Because software tools can read from standard input and write to standard output, they can be connected via shell pipes to form pipelines, like factory assembly lines<\/a>. UNIX has many software tools, including awk, cat, cut, du, fold, grep, od, sed, sort, tr, and uniq.<\/p>\n Another class of programs are device drivers, which are not even attached to a terminal. A program that is not attached to a terminal is called a daemon in UNIX. A commonly used, but inaccurate, de\u001cfinition of a daemon<\/a> is that it is a “background” process<\/a>. To be precise, it is a process that executes without an associated terminal or login shell, waiting for an event to occur. The event might be a user request for a service such as printing or connecting to the Internet, or a clock tick indicating that it is time to run. The word “daemon” is from Greek mythology<\/a>, and refers to a lesser god who did helpful tasks for the people he or she protected. Daemons are like these lesser gods; they are created at boot time, and exist, in hiding, ready to provide services when called upon.<\/p>\n Because daemons must not be connected to a terminal, one of their \u001cfirst tasks is to close all open fi\u001cle descriptors (in particular, standard input, standard output and standard error). They usually make their working directory the root of the fi\u001cle system. They then take additional steps to break their association with any shell or terminal, among which are leaving their process group and registering their intent to ignore all incoming signals. The concept of process groups will be discussed in Chapter 8. Signals are covered later in this chapter.<\/p>\n Daemon process names typically end in ‘d’. This is one way to identify a daemon process in the output of the ps -ef command; \u001cnd the names ending in “d” as in ftpd, httpd, lpd, sshd, syslogd, and telnetd. Daemons will be covered thoroughly in Chapter 8.<\/p>\n Another category of programs are those that are tied to the user terminal in an inextricable way, because they customize the terminal for their own use. Programs that interact with the user through the terminal, such as text editors (vi, nano, or emacs), pagers (more and less), terminal-based administrative tools such as top, games (snake, worm, and chess), and terminal-based mail clients (pine and mailx), are tightly coupled to the terminal and must control its settings and attributes. They cannot use the standard input and output streams for communicating with the user because these lack the types of controls that a terminal has. These types of programs usually need to control<\/p>\n whether or not characters are echoed,<\/p>\n the number of characters that are bu\u001bffered, if any,<\/p>\n the movement of the cursor on the screen,<\/p>\n whether certain key presses should have their default meaning or have application-de\u001cfined meaning,<\/p>\n whether timeouts should occur on input,<\/p>\n whether signals such as Ctrl-C should be ignored, queued, or handled immediately.<\/p>\n We already saw how to control the state of the terminal using stty at the command level and the tcgetattr() and tcsetattr() functions at the programming level. Here we will explore the various modes into which we can put the terminal for the benefi\u001ct of creating interactive programs.<\/p>\n","protected":false},"excerpt":{"rendered":"5.1.2 Daemons<\/h3>\n
5.1.3 Interactive User Programs<\/h3>\n