So there I was. Trying to append to $PATH. Uh oh! I accidentally unset $PATH! For whatever reason I ran

$ ls
bash: ls: command not found

To be expected. Then I ran

$ echo $PATH

Is echo some sort of special case? Why isn't it on $PATH? Is it built in to bash?

  • 12
    Welcome to Ask Ubuntu! “I accidentally unset $PATH!” Not really, you seem to have set it to a not wanted value. Since your PATH now contains $PATH literally, you must have used single quotes (') instead of double quotes ("): export PATH='$PATH:/home/jon/.local/bin', haven’t you?
    – Melebius
    Feb 5, 2020 at 11:15

3 Answers 3


echo is a bash builtin. It does not use the $PATH to find the echo program, instead bash has it's own version of echo which is used instead of the echo program located in your $PATH

read more here: Bash Builtins (Bash Reference Manual)

  • 2
    There's also /bin/echo, which would have vanished when OP unset $PATH
    – waltinator
    Feb 5, 2020 at 3:56
  • 13
    @waltinator except, if you call it as /bin/echo it would still work regardless of PATH, and if you call it as echo, you get the builtin and not /bin/echo :)
    – hobbs
    Feb 6, 2020 at 4:39

In addition to what Minijack mentioned, you can check what a command is by using the type builtin.

$ type echo
echo is a shell builtin

On the other hand, which can be used to check for executables specifically. Once you unset $PATH, you'll get something like

$ which echo
/usr/bin/which: no echo in ((null))

Whereas with your path set you get


You can check man builtins for list and desription of various builtins. For example, [ and test are also builtins.

EDIT: which works for me even without PATH because of an alias that uses an absolute path

  • 7
    Without PATH, even which wouldn't be found, right? Feb 5, 2020 at 15:32
  • @AngewisnolongerproudofSO and without PATH, also man builtins wouldn't work :-)
    – andreee
    Feb 5, 2020 at 15:53
  • 4
    There's no reason to ever use which. If you want to know about executables, use type with -a, -P, or -p.
    – wjandrea
    Feb 5, 2020 at 21:47
  • 1
    @wjandrea what's wrong with which? Feb 6, 2020 at 17:40
  • 1
    By default type simply returns the first hit. If you want to see all of them, use type -a echo which will include the one found at /usr/bin. The difference between type and which is that which only looks at directories in your $PATH, while type will look everywhere, including shell builtins, functions etc. As a general rule, type is always preferred over which, for this reason among others.
    – terdon
    Feb 7, 2020 at 12:12

The model employed by the Single Unix Specification (a.k.a. IEEE 1003.1) is that whether a command is built into a shell is a mere optimization, and the behaviour (if invoked in a conformant manner) should be the same for a built-in version of a command as for an external version. (This is regular built-ins, that is. Special built-ins are another matter.) In particular, if the command is not found as an external in a PATH search, the built-in version is not to be executed.

This is indeed what happens with one shell. You'll find that the Watanabe shell conforms to the SUS. In its posixly-correct mode, if echo is not on the path, the built-in echo command in the Watanabe shell will not be executed.

But the 93 Korn, Debian Almquist, Z, and Bourne Again shells in their most conformant modes still all execute built-ins even if there is no corresponding executable on PATH. That is what is happening here for you. The Bourne Again shell has a built-in echo command, and several others besides. It is executing that, even though it has not found an external echo command in a PATH search.

(Note that there are quite a few ways to invoke echo in a non-conformant manner, or at least in a manner where the result is unspecified: Using -n; using a backslash in any argument; using -e; using other things expecting them to be command options or end of options markers. These not only reveal whether it is a built-in echo, but even to an extent reveal what shell is in use. Fortunately, you did not hit any of them. ☺)

Further reading

  • 1
    I suspect the reason a lot of shells stil invoke a builtin even if the exacutable is present is the same they have it as a builtin to begin with, speed. Searching for the exacutable wastes time, and they have those builtins specifically to save time. Feb 8, 2020 at 9:01

You must log in to answer this question.

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