Return to Revisions

Adding this as well (Classic Shell Scripting by Robbins and Beebe is a great book):

The shell has a number of commands that are built-in. This means that the shell itself executes the command, instead of running an external program in a separate process. Furthermore, POSIX distinguishes between “special” built-ins and “regular” built-ins. [Most regular built-ins] have to be built-in for the shell to function correctly (e.g., read). Others are typically built into the shell only for efficiency (e.g., true and false). The standard allows other commands to be built-in for efficiency as well, but all regular built-ins must be accessible as separate programs that can be executed directly by other binary programs. The distinction between special and regular built-in commands comes into play when the shell searches for commands to execute. The command-search order is special built-ins first, then shell functions, then regular built-ins, and finally external commands found by searching the directories listed in $PATH. This search order makes it possible to define shell functions that extend or override regular shell builtins. This feature is used most often in interactive shells. For example, suppose you would like the shell's prompt to contain the last component of the current directory's pathname. The easiest way to make this happen is to have the shell change PS1 each time you change directories. You could just write your own [cd] function [for this]. There is one small fly in the ointment here. How does the shell function access the functionality of the "real" cd command?...What's needed is an "escape hatch" that tells the shell to bypas the search for functions and access the real command. This is the job of the command built-in command.

I second @mosvy: it appears the standard and normative text don't match (quite absurd indeed).