Is there any intrinsic difference between a builtin command and another command which can nominally do the same thing?

eg. Do builtins get "special" treatement? ... is there less overhead running them? .. or are they just simply 'built in'; like the dashboard of your car?

...and is there a definitive (current) list of these builtins?


From your comments, you seem to be confused about exactly what a shell is. The kernel is responsible for managing the system. It's the part that actually loads and runs programs, accesses files, allocates memory, etc. But the kernel has no user interface; you can only communicate with it by using another program as an intermediary.

A shell is a program that prints a prompt, reads a line of input from you, and then interprets it as one or more commands to manipulate files or run other programs. Before the invention of the GUI, the shell was the primary user interface of an OS. On MS-DOS, the shell was called command.com and few people ever tried to use a different one. On Unix, however, there have long been multiple shells that users could pick from.

They can be divided into 3 types. The Bourne-compatible shells use the syntax derived from the original Bourne shell. C shells use the syntax from the original C shell. Then there are nontraditional shells that invent their own syntax, or borrow one from some programming language, and are generally much less popular than the first two types.

A built-in command is simply a command that the shell carries out itself, instead of interpreting it as a request to load and run some other program. This has two main effects. First, it's usually faster, because loading and running a program takes time. Of course, the longer the command takes to run, the less significant the load time is compared to the overall run time (because the load time is fairly constant).

Secondly, a built-in command can affect the internal state of the shell. That's why commands like cd must be built-in, because an external program can't change the current directory of the shell. Other commands, like echo, might be built-in for efficiency, but there's no intrinsic reason they can't be external commands.

Which commands are built-in depends on the shell that you're using. You'll have to consult its documentation for a list (e.g., bash's built-in commands are listed in Chapter 4 of its manual). The type command can tell you if a command is built-in (if your shell is POSIX-compatible), because POSIX requires that type be a built-in. If which is not a built-in in your shell, then it probably won't know about your shell's built-ins, but will just look for external programs.

  • Applications communicate with the kernel by issuing interrupts, actually. – Nathan Osman Apr 16 '11 at 22:00
  • 11
    @George: Applications communicate with the kernel by issuing syscalls, which depending on the OS and architecture may or may not use interrupts. Users, as a rule, don't issue interrupts. – Gilles 'SO- stop being evil' Apr 16 '11 at 22:05
  • 2
    @cjm: It sounds so simple when you explain it like that :)... you've certainly helped clear the fog... just a light mist now.. (actually that's just what the weather is like here, this morning... pleasantly misty ;) ... thanks – Peter.O Apr 16 '11 at 22:15
  • @Gilles: Really? I thought all user mode programs communicated with the kernel via interrupts (on certain architectures, of course). – Nathan Osman Apr 16 '11 at 22:16
  • 2
    @cjm Very thorough and instructive answer. I learned a lot reading it. :) – ankush981 Nov 28 '15 at 6:42

There are three levels of built-in utilities:

  • Some utilities are really part of the shell as a programming language, even though they are not reserved words. They are control flow utilities (., :, break, continue, return, trap, exit, exec, eval), parameter-related utilities (set, unset, shift, export, readonly, local¹, typeset¹), alias utilities (alias², unalias²) and times³. These special built-ins get special treatment:

    • If you pass the wrong arguments to a special built-in, the shell itself may abort, rather than just skipping to the next command after displaying an error message.
    • The pre-assignment syntax foo=bar utility has a different meaning: it's an ordinary parameter assignment (i.e. equivalent to foo=bar; utility), instead of assigning to the environment for the duration of the utility only.
  • Some utilities need to be implemented inside the shell because they act on the shell's internal settings. This includes:

    • utilities that act on the shell's current directory such as cd, dirs, pushd, popd;
    • job control utilities such as bg, disown, fg, jobs, wait;
    • utilities that read or manipulate other shell attributes such as builtin, command, hash, read, type, ulimit, umask;
    • utilities related to interactive features, when they're present, such as fc, history, bind.
  • Some utilities are typically implemented as built-ins purely for performance: echo, printf, test, true, false.

Advanced shells such as bash, ksh and zsh typically have more built-ins, often to implement non-standard features (usually for interaction). The manual of each shell will tell you what commands are built-in, though some shells (zsh, at least) support dynamically-loadable modules that can provide more built-ins.

¹ Unknown to POSIX, but special in ksh and several other shells.
² Ordinary in POSIX, but special in ksh and several other shells.
³ In ksh, times is a wrapper around the time keyword: it's an alias for { { time;} 2>&1;}. Note that POSIX allows time to be an external utility with ordinary parsing or a keyword that applies to a whole pipeline (which it is in ksh, bash in zsh).

  • 3
    These distinctions are the really important ones. – dmckee Apr 16 '11 at 19:24
  • Quick question, so what does "ordinary parameter assignment" mean when we do while IFS= read -r line ? – Sergiy Kolodyazhnyy Dec 15 '17 at 16:37
  • @SergiyKolodyazhnyy read is not a special builtin, so IFS=read sets the variable only for the duration of the command. – Gilles 'SO- stop being evil' Dec 15 '17 at 19:56

A builtin is a command provided by the shell, rather than by an external program. Here are the lists for bash's builtins (they are also listed in the bash man page) and zsh's builtins. ksh provides a list by running builtin.

To know if a particular command is a builtin, you can run type command. Try type for and type ls to see this.

  • type seems to do the trick; thanks for that... but I still wonder what "provided by the shell" means... Perhaps I need to more fully understand how the shell relates to the kernel.... but not at 2 AM.. I'll come back to this tomorrow – Peter.O Apr 16 '11 at 16:48

Every distro and shell has a different collection of commands vs builtin shell functions. Generally the idea is that shells build-in the most common and simple functions to save time, speed, and integrate will with the rest of their feature set. The overhead is much lower since it doesn't have to launch another system process. However it is possible to mix and match. You might run one shell that has a buildin for something, but have that command on your system too. Usually the builtin would take priority, but you could control that.

You can easily find out whether a specific command is a builtin or not by running type mycommand. Most shell man pages also have a list of their builtins.

Edit: Use type to find out whether a command is a builtin, and if not which to learn where it will be executed from.

  • @Caleb: thanks for your comment, but it leaves me wondering about what exactly a "system process" is.. I keep seeing references to then but I don't understand whwere the distinction lies.... (btw I can't see how 'which' is an absolute indicator).. eg..'which echo=>"/bin/echo" and type echo=>"echo is a shell builtin", but 'which dd=>"/bin/dd" and type dd=>"dd is /bin/dd" ... so, I'm part way there .... – Peter.O Apr 16 '11 at 16:44
  • "System procses" just means it is being started up as an independent application managed by the kernel. The alternative in the case of builtins is just running a sub-function in the already running code of your shell. In the example you give, type is the better indicator of what is being run, but you notice echo is both a builtin and there is an application with that name. If your shell didn't have a builtin the system one would get run. – Caleb Apr 16 '11 at 16:53
  • 2
    which is not necessarily a built-in command, and if it's not, it won't know about the shell's built-ins. POSIX requires that type be a built-in command, so it always knows about built-ins. – cjm Apr 16 '11 at 17:34
  • Many systems ship with an alias of which to type or some set of options e.g. alias which='type -path' - this could be the source of confusion. – Random832 Apr 16 '11 at 19:35
  • 1
    I can't upvote this, until which is replaced by type. I used which, over and over again, not knowing of type and was very astonished to lern, that which is only right, if deciding between programs. – user unknown Apr 16 '11 at 23:01

Your Answer

