Linux benefits from the strongly-principled ethos of Unix design. Programs communicate via text, you can combine them via pipelines, and they do one thing well. Beyond that, though, programs can act very differently and exhibit many different behaviors.
Background Processes
A multitasking operating system, like Linux, runs many different programs simultaneously. Those that run without the user directly controlling them are known as background processes. There’s only really one type of background process, commonly known as a “daemon.”
1. Daemon
The term “daemon” is a strange one, but it just means “background process.” A daemon typically uses tricks to keep itself running, whatever else happens on the system. For example, it will fork a copy of itself that runs independently of the shell. Services like inetd or launchd can do this on a program’s behalf, and are daemons themselves.
Daemons often end their name with “d,” for example httpd (the Apache web server), inetd (internet service daemon), and systemd.
If an external program—or the user—needs to communicate with a daemon, it usually does so by sending a signal instructing the daemon to restart or reload its configuration, for example. You can use the ps tool to discover what daemons are running on your system.
Command Line Interface
Most Linux programs have a command line interface, meaning you use them by typing text commands. These are the most common and, usually, easiest-to-use terminal programs. These programs usually start, run quickly, then stop once they are finished.
2. Cantrip
The simplest type of program—unofficially named “cantrip”—will simply act with no input or output. These programs often operate on files or perform related sysadmin tasks. The rm program, which deletes a file, is a typical example:
rm myfile.txt
If the file exists, rm will delete it and your terminal will print your prompt on the following line, waiting for the next program or command:
The rm command has some options to control the way it runs, but its simplicity lies in its lack of input and output.
3. Filter
Many Linux programs are the complete opposite: they require input and produce output. Often, these programs modify their input in some way, and there are plenty of them: cut, head, sort, uniq, etc.
The grep command demonstrates the meaning of filter particularly well: it scans each line of input, reproducing it as output if it fulfills a certain condition. In grep’s case, the condition is a regular expression which matches a certain pattern of text:
Filters are excellent at manipulating data, and are commonly used in pipelines that chain several commands together to carry out a complex task. You can even combine these tools to build a rudimentary database.
4. Sink
In contrast with filters, there are very few sinks. This type of program takes input, but produces no output—at least, no on-screen output in your terminal. One example is lpr, the line printer, which prints a file or standard input on paper.
Sinks often output to media other than the screen, like the espeak program which converts text to audio speech.
5. Source
The opposite of a sink is a “source,” a program that produces output without processing any input. Source programs get their data from elsewhere: the environment or a file named as an argument, for example.
The ls program uses various approaches to list files, but it never processes standard input. In its simplest case, ls doesn’t even need any arguments:
ls
By default, ls operates on the current directory, printing its contents. You can show details of a different directory, file, or set of files by passing command-line arguments:
ls /tmp
ls /etc/passwd
ls ~/.*
6. Compiler
A compiler is, by far, the most complicated type of CLI program, typically reserved for programming. A compiler will run like any other program, but it may take longer to finish since its work can be quite involved.
Their names often end in “c” for “compiler:” cc, javac, or rustc. A compiler is a bit like a cantrip, but it always works with files, transforming one type of data into another.
The c compiler, cc, demonstrates the typical behavior of a compiler:
cc file1.c file2.c -o program
This command runs the compiler against two files—file1.c and file2.c—generating a third file named program. Here, the “-o” argument stands for “output file.”
It’s important to note that a compiler may source additional files, depending on its task or the underlying language. A c program like file1.c can include a header file (e.g. file1.h) which the compiler will locate and use to generate the final program, even though it’s not explicitly named when you run the command.
This is part of what makes compilers so complicated: they can do many things behind the scenes without having to be directly instructed to do so.
Interactive Programs
The previous programs all run non-interactively. When you run them, you don’t have direct control over how they operate. The final two types of programs are very different.
7. Line-by-line
The simplest form of interaction is one line at a time. At the beginning of Unix history, these commands were quite commonplace because they ran on teletypes: glorified typewriters that operated one line at a time.
Nowadays, these programs really feel like they’re “interactive in name only,” but in the 1960s, they were quite revolutionary. If you’re brave, you can relive the old days with the original text editor, ed:
This ed transcript shows commands that write the text “hello world” to a file named foo.txt. Some of those lines are typed by the user: “a” is a command to append text to a buffer, “,p” prints the current buffer, and “w” writes the buffer to a file. After writing, ed reports the number of bytes written, in this case 13.
If you remember one thing about ed, it should be the “q” command that quits the program. It won’t save any new text you’ve entered, but if you ever accidentally run ed, typing “q” followed by Enter will let you leave it as quickly as possible!
As you can see, text editing line-by-line is an arduous process that can be error-prone. The ed program can be useful in an emergency, but line-by-line programs are generally obsolete.
8. TUI
A far better alternative for interactive programs, especially for text editors, is the TUI style: text-user interface. The name distinguishes these programs from GUI apps, which use graphics to achieve more-or-less the same type of outcome: a truly interactive program.
The text editor, vim, is still heavily command-based, but you can use it to jump around in a text file, search for text, delete whole chunks, and see everything happening on-screen, in real time. Modern TUIs make extensive use of color and box-drawing characters to approximate a graphical interface:
While you won’t always see references to these types of programs, it’s useful to know they exist and understand what they do. Each type has particular strengths and can be used in certain contexts to achieve a variety of tasks.
