What is the difference between a builtin command and one that is not?

Question

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?

Solution 1

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 people wouldn't usually change it. 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.

Solution 2

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).}

Solution 3

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.

Solution 4

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.

View more solutions

Comments

[Peter.O]

@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]

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

[tcoolspy]

"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.

[cjm]

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.

[dmckee --- ex-moderator kitten]

These distinctions are the really important ones.

[Random832]

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.

[Peter.O]

type which which is /usr/bin/which .. which which which is hashed (/usr/bin/which)` .. type type type is a shell builtin .. I'm not sure what that last one means, but it looks interesting :) .. which type returned nothing..

[dbush]

Applications communicate with the kernel by issuing interrupts, actually.

[Gilles 'SO- stop being evil']

@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.

[Peter.O]

@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

[dbush]

@Gilles: Really? I thought all user mode programs communicated with the kernel via interrupts (on certain architectures, of course).

[user unknown]

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.

[Chris Jester-Young]

@George Edison: Never heard of sysenter? That ain't no interrupt. ;-)

[cjm]

@George, @Gilles, @Chris, none of your comments have anything to do with this question or my answer. Maybe somebody should ask a question about how apps communicate with the kernel, and take this discussion there. @fred, you're welcome. :-)

[dbush]

@Chris: You're right. I learned something new :) (I admit that I had to Google 'sysenter' to figure out that it was an instruction.)

[ankush981]

@cjm Very thorough and instructive answer. I learned a lot reading it. :)

[Gilles 'SO- stop being evil']

@SergiyKolodyazhnyy read is not a special builtin, so IFS=read sets the variable only for the duration of the command.