I've always wondered why cd isn't a program, but never managed to find the answer.
Anyone know why this is the case?
7 Answers
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:
cd foo- the
cdprocess starts - the
cdprocess changes the directory for the cd process - the
cdprocess exits - your shell still has the same state, including current working directory, that it did before you started.
answered May 16, 2012 at 19:41
-
9Your five steps are correct but "if
cdwas a program it would work like this" should be "whencdis used in its external program implementation, it does work like this".– jlliagreCommented May 19, 2012 at 12:21 -
2Not 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.– JasonCommented Oct 31, 2014 at 18:48
-
A link to the source code of the
cdcommand indash: git.kernel.org/pub/scm/utils/dash/dash.git/tree/src/cd.c– Daniel FCommented 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.
Gilles 'SO- stop being evil'
843k199 gold badges1.8k silver badges2.2k bronze badges
answered May 16, 2012 at 20:44
-
12...so, apparently, POSIX mandates that there shall be an independent
cdexecutable, 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 -
6Oh well, if it's true, that wouldn't be the stupidest thing in POSIX.– KazCommented May 16, 2012 at 23:06
-
6The POSIX cd page also says "Since cd affects the current shell execution environment, it is always provided as a shell regular built-in.".– MikelCommented 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.– jlliagreCommented 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.– jlliagreCommented 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, andexec) cannot be implemented outside of the shell because they directly manipulate the shell itself. Thehistory,getopts,kill, orpwdbuiltins, 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. :)
answered May 17, 2012 at 1:09
-
-
8Good 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 ...– jlliagreCommented May 17, 2012 at 6:30
-
9I think I'm going to try again next year, citing the POSIX issue. ;) Commented May 17, 2012 at 7:03
-
-
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.– user18925Commented May 17, 2012 at 16:11
-
2There is a very good technical reason that
cdis 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!– user18925Commented May 17, 2012 at 16:32
-
5
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.
-
3While 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?– ErfankamCommented May 25, 2012 at 7:52
-
3That 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.– ErfankamCommented May 25, 2012 at 8:56
-
4No, I'm telling you that
$PWDonly 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 callpwdto find it. Any standalone program depending on the value of$PWDwill be unreliable. Commented May 25, 2012 at 9:26
cdcommand was a separate program. The shell handled it specially in that it did notfork, justexec. And whencdwas done, it would execsh. I don't know if this is a true story.chdirsyscall. sources: v1 v5 v7 (first version with Bourne shell)cdthat I had read. I was clearly wrong about aspect of it, now that @jlliagre has filled in the details.