(Note that this is entirely an academic question... I'm just curious about the answer, not trying to solve any particular problem.)

From the ECHO(1) manual page (GNU echo):

NOTE: your shell may have its own version of echo, which usually supersedes the version described here. Please refer to your shell's documentation for details about the options it supports.

From the ECHO(1) manual page (BSD echo):

Some shells may provide a builtin echo command which is similar or identical to this utility. Most notably, the builtin echo in sh(1) does not accept the -n option. Consult the builtin(1) manual page.

When running echo from the shell, an internal command is run, but specifying a full path e.g. /bin/echo, the external program is run.

What's the justification for having the shell itself implement that particular command. There are definitely commands which must be implemented by the shell (e.g. cd, read, etc.) but why echo? Is it because it's used so often, and the time-savings for avoiding process setups and context-switches is measurable -- especially historically?

Ignoring the fact that e.g. bash has a huge number of not-strictly-necessary features, why didn't things like expr, [/test, mkdir, rmdir, etc. make it into shells if the speed factor was important? Things like mkdir and rmdir whose implementation is almost literally a single call to a libc function would seem to be obvious candidates for inclusion.


1 Answer 1


The speed factor is one reason. This makes especially sense for commands which are often used without any file arguments like echo, test, printf, etc. So they can be done without any file access, neither reading any file argument nor the command itself.

Other commands like kill also benefit from supporting shell job control syntax, like kill %1.

Some shells even implement other "higher level" commands like mv in zsh for adding functionality like simple shell-style pattern renaming.

Not the answer you're looking for? Browse other questions tagged .