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

Anyone know why this is the case?

  • 9
  • 2
    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
    Commented May 17, 2012 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
    Commented May 17, 2012 at 5:33
  • 3
    @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
    Commented May 17, 2012 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
    Commented May 17, 2012 at 8:23

7 Answers 7


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.
  • 9
    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
    Commented May 19, 2012 at 12:21
  • 2
    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
    Commented Oct 31, 2014 at 18:48
  • A link to the source code of the cd command in dash: git.kernel.org/pub/scm/utils/dash/dash.git/tree/src/cd.c
    – Daniel F
    Commented Oct 19, 2023 at 15:44

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.

  • 12
    ...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. Commented May 16, 2012 at 21:39
  • 6
    Oh well, if it's true, that wouldn't be the stupidest thing in POSIX.
    – Kaz
    Commented May 16, 2012 at 23:06
  • 6
    The POSIX cd page also says "Since cd affects the current shell execution environment, it is always provided as a shell regular built-in.".
    – Mikel
    Commented May 17, 2012 at 0:57
  • 6
    @Kaz, they are not completely different things. They do the same thing but only the builtin one affects the current shell.
    – jlliagre
    Commented May 17, 2012 at 5:32
  • 13
    @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
    Commented May 17, 2012 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
    Commented May 17, 2012 at 5:13
  • 8
    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
    Commented May 17, 2012 at 6:30
  • 9
    I think I'm going to try again next year, citing the POSIX issue. ;) Commented May 17, 2012 at 7:03
  • 6 years later: Well, did you? Commented Nov 20, 2018 at 15:55
  • 1
    @PeterA.Schneider: I thought it was clear that I was joking, so to be clear, no, I'm not actually going to expend a bunch of effort trying to get this into OSes and OS-like projects such as Cygwin that currently lack /bin/cd. If you want to take my code and make that your own personal quest, you're welcome to do so. Commented Nov 20, 2018 at 16:01

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
    Commented May 17, 2012 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. Commented May 17, 2012 at 16:22
  • The highest ranked answer was the worst i ever read! But huh? Who am i!
    – user18925
    Commented May 17, 2012 at 16:32
  • 5
    But it answers the question why. Commented May 18, 2012 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.) Commented May 23, 2012 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
    Commented May 25, 2012 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 /. Commented May 25, 2012 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
    Commented May 25, 2012 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. Commented May 25, 2012 at 9:26

You must log in to answer this question.

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