I've always wondered why cd isn't a program, but never managed to find the answer.

Anyone know why this is the case?

  • 8
  • 1
    I remember reading (I can't find where) that the original unix cd command was a separate program. The shell handled it specially in that it did not fork, just exec. And when cd was done, it would exec sh. I don't know if this is a true story. – camh May 17 '12 at 2:18
  • What would be the point? If it's going to add special handling, it might as well just call the chdir syscall. sources: v1 v5 v7 (first version with Bourne shell) – Mikel May 17 '12 at 5:33
  • 2
    @camh, it is a true story. I have read that too in an article written by Dennis M. Ritchie, “The Evolution of the Unix Time-sharing System”, AT&T Bell Laboratories Technical Journal 63(6), Part 2, Oct. 1984. – jlliagre May 17 '12 at 5:57
  • @Mikel: I agree it appears pointless, but I was just relaying a story about cd that I had read. I was clearly wrong about aspect of it, now that @jlliagre has filled in the details. – camh May 17 '12 at 8:23
up vote 162 down vote accepted

The cd command modifies the "current working directory", right?

"current working directory" is a property that is unique to each process.

So, if cd was a program it would work like this:

  1. cd foo
  2. the cd process starts
  3. the cd process changes the directory for the cd process
  4. the cd process exits
  5. your shell still has the same state, including current working directory, that it did before you started.
  • 7
    Your five steps are correct but "if cd was a program it would work like this" should be "when cd is used in its external program implementation, it does work like this". – jlliagre May 19 '12 at 12:21
  • 1
    Not being a systems programmer, nor really having a deep knowledge of the ins and outs of interacting with the shell, I would have expected the shell to expose its current working directory, and cd to be a program that accesses and alters that property. Understanding, after looking at this answer, that that's probably sub-optimal to how it actually works for many reasons. – Jason Oct 31 '14 at 18:48

cd in addition to being a shell builtin, is actually also a program on POSIX compliant OSes. They must provide independent executables for regular utilities, like cd. This is for example the case with Solaris, AIX, HP-UX and OS X.

Obviously, a builtin cd is still mandatory as its external implementation doesn't change the current shell directory. However, the latter can still be useful. Here is an example showing how POSIX envision how this cd command could be used:

find . -type d -exec cd {} \;

On a POSIX system, this oneliner will report an error message for all directories you aren't allowed to cd in. On most Gnu/Linux distributions, it fails with that error message though:

find: `cd': No such file or directory

And here is the answer to your question, "Why is cd not a program?" by one of the original Unix co-author. On a very early Unix implementation, cd (spelled chdir at that time) was an external program. It just stopped working unexpectedly after fork was first implemented.

Quoting Dennis Ritchie:

In the midst of our jubilation, it was discovered that the chdir (change current directory) command had stopped working. There was much reading of code and anxious introspection about how the addition of fork could have broken the chdir call. Finally the truth dawned: in the old system chdir was an ordinary command; it adjusted the current directory of the (unique) process attached to the terminal. Under the new system, the chdir command correctly changed the current directory of the process created to execute it, but this process promptly terminated and had no effect whatsoever on its parent shell! It was necessary to make chdir a special command, executed internally within the shell. It turns out that several command-like functions have the same property, for example login.

Source: Dennis M. Ritchie, “The Evolution of the Unix Time-sharing System”, AT&T Bell Laboratories Technical Journal 63(6), Part 2, Oct. 1984, pp.1577–93

Unix Version 1 (March 1971) chdir manual page states:

Because a new process is created to execute each command, chdir would be ineffective if it were written as a normal command. It is therefore recognized and executed by the Shell.

  • 8
    ...so, apparently, POSIX mandates that there shall be an independent cd executable, but that it shall do nothing (except possibly emit error messages if called with the wrong arguments). Weird. – Ilmari Karonen May 16 '12 at 21:39
  • 4
    Oh well, if it's true, that wouldn't be the stupidest thing in POSIX. – Kaz May 16 '12 at 23:06
  • 4
    @Ilmari Karonen: It is incorrect to state the cd command does nothing. It tests if you can change your directory to the provided argument and returns a status accordingly. – jlliagre May 17 '12 at 5:00
  • 5
    @Kaz, they are not completely different things. They do the same thing but only the builtin one affects the current shell. – jlliagre May 17 '12 at 5:32
  • 12
    @Kaz: Please don't call me silly while I'm just reporting a fact. You might agree or disagree with POSIX but don't shoot the messenger. – jlliagre May 17 '12 at 5:37

From the Bash introduction (What is a shell?):

Shells also provide a small set of built-in commands (builtins) implementing functionality impossible or inconvenient to obtain via separate utilities. For example, cd, break, continue, and exec) cannot be implemented outside of the shell because they directly manipulate the shell itself. The history, getopts, kill, or pwd builtins, among others, could be implemented in separate utilities, but they are more convenient to use as builtin commands. All of the shell builtins are described in subsequent sections.

For April Fool's this year, I wrote a standalone version of cd.

No one got the joke. Sigh.

Anyone who isn't sure that cd must be built into the shell should download it, build it, and try it.

Read its man page, too. :)

  • Really useful code! :-) – dschulz May 17 '12 at 5:13
  • 6
    Good you to see someone working for making Gnu/Linux more POSIX compliant. Your implementation is not only a good joke but actually something missing from Linux distributions ... – jlliagre May 17 '12 at 6:30
  • 7
    I think I'm going to try again next year, citing the POSIX issue. ;) – Warren Young May 17 '12 at 7:03

The cd command in shell cannot be a separate process because in Unix there is no mechanism to change the current working directory of a different process (not even the parent process).

If cd was a different process then it would have to change the current working directory of its parent (shell) which is not possible in Unix. Instead cd is a special built in command. The shell calls functions like chdir() and fchdir() changing its own current working directory.

Note : the kernel stores the inode number of the current working directory for every process. The child process inherits it's cwd from its parent.

cd is a shell built-in command. As easy as is. The man cd says it all. the cd command changes the working directory for all interpreters and (in a threaded environment) all threads.

  • Because the shell is the environment which takes care about your current working dirs ($PDW...) or cdable_vars. This builtin is ultimately the way that all user-visible commands should change the current working directory. You are able to test it that way: compile the bash without cd.c and try to write your own cd script, which trys to take care of all environment cdable_vars. This question is also more a developer related. I bet they could answer you this question in more deeper detail. – user18925 May 17 '12 at 16:11
  • 2
    There is a very good technical reason that cd is built-in. I would suggest you read the highest ranked answers and consider how your answer can be improved. – Thorbjørn Ravn Andersen May 17 '12 at 16:22
  • The highest ranked answer was the worst i ever read! But huh? Who am i! – user18925 May 17 '12 at 16:32
  • 3
    But it answers the question why. – Thorbjørn Ravn Andersen May 18 '12 at 11:21

I think one thing missing in people answer is that current directory is a environment variable that each program can change. If you use 'export' command to see your current environment variables list, you will have:

declare -x PWD="/home/erfan"

in your results. Thus by 'cd' command we just want to modify this internal variable. I think if we try, we can chage the PWD variable of any pty in shell, of course. Like:

cder    #change current PTY $PWD variable

But I think there s no need in normal cases. In another word, we take help from bash(or any shell) to modify its internal variable defined.

  • 3
    While it's true that Bourne shells expose the current working directory (CWD) as $PWD, that is not the primary storage location; the actual location is in the kernel's per-process structure. It is therefore incorrect to say that the CWD "is an environment variable." If it worked the way you suggest, this C two-liner would print the .. path, not the path you started it from: #include <stdlib.h> int main(void) { chdir(".."); puts(getenv("PWD")); } (C shells expose the CWD as %cwd instead, by the way.) – Warren Young May 23 '12 at 16:59
  • lets add some another lines to your app. #include <stdlib.h> int main(void) { chdir(".."); puts(getenv("PWD")); setenv(P"PWD", "/", 1); puts(getenv("PWD")); } What will we have as results? – Erfankam May 25 '12 at 7:52
  • 3
    That will just overwrite the value of a variable, with no side effect on the CWD. This is a better test to show that: #include <unistd.h> int main(void) { char ac[99]; setenv("PWD", "/", 1); puts(getcwd(ac, sizeof(ac))); } It will show the directory you started the program from, not /. – Warren Young May 25 '12 at 8:02
  • I think every process has a working directory and path variable too. Thus you by chdir just change this attribute of process. Shell has this attribute too and by cd we modify this attribure. – Erfankam May 25 '12 at 8:56
  • 4
    No, I'm telling you that $PWD only has meaning to the Bourne shell. It is just a way for the shell to communicate something it knows to shell scripts so they dont have to call pwd to find it. Any standalone program depending on the value of $PWD will be unreliable. – Warren Young May 25 '12 at 9:26

Your Answer


By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.