UNIX for Dummies Questions & Answers

As it happens, AIX and Solaris have the executable
/usr/bin/cd however, RedHat does not. And yes...
ksh and bash do have a "cd" built in. It looks
like the source for it is there but not the
executable.

Folks, the current working directory is a datum that is stored on a per-process basis. The chdir(2) changes this value for the current process. After a fork(2), the child process will inherit the cwd from its parent.

Now think about the code:
cd /etc
cat passwd

This is being executed by a shell. Let's say the shell has a pid of 1200. When the shell encounters the "cd /etc" line, we really must have the cd command executed by the current shell as a built-in. So then shell the will execute the c code "chdir(/etc)" which sets the shell's cwd to /etc. Next, the shell encounters the "cat passwd" command. This is not a built-in. So the shell must fork(2). The parent shell, pid 1200, will simply wait(2) for the child. But the child process, let's say it got pid 2200, will exec(2) the cat program. When cat(1) starts to run, it still has "/etc" as its cwd. So when it opens the file called passwd, it will actually be opening "/etc/passwd". Eventually, pid 2200, will exit. This will cause pid 1200 to finally return from its wait call. Pid 1200 can get pid 2200's exit code from the wait call. But that's the only thing it will get from pid 2200.

Now think about:
/usr/bin/cd /etc
cat passwd

Here we have a problem. /usr/bin/cd is not a built-in. So the shell forks creating process pid 2200. 2200 will then exec(2) /usr/bin/cd. Now process 2200, which is now cd will invoke chdir("/etc") and so now it's cwd is indeed /etc. But now it exits. The shell, still pid 1000, returns from its wait call. But we have not changed the shell's current working directory. So now the shell encounters "cat passwd". It forks, creating pid, say. 2201. Process 2201 will then exec the cat command. But the cat command has inherited the cwd from the shell. It has no way to know that previously the shell executed "/usr/bin/cd /etc". We are in the wrong directory. This is why cd must be a shell built-in. cd was built-in even in the first bourne shell.

From a shell, any shell, try:
cd /
cat passwd
/usr/bin/cd /etc
cat passwd
pwd
cd /etc
cat passwd
pwd

It is only recently that /usr/bin/cd has started to exist. Unix got along fine without it for decades and it would get along fine if it vanished. It is largely useless and very misleading as this thread has shown. The only semi-rational reason to ever code something like:
/usr/bin/cd /etc
would be if you wanted to test whether or not you can sucessfully "cd /etc". The exit code from /usr/bin/cd indicates whether or not the chdir succeeded. You could check the exit code. But I have a suspicion that /usr/bin/cd may be someone's idea of a joke.

To further clarify all this stuff, /usr/bin/cd is not a joke or fluke...
its' purpose is when "cd" is invoked without any arguments,
it will change the current working directory of the invoking
shell to the HOME directory (provided HOME is set).

Having said that, bash and newer versions of ksh and sh
may now act this way thereby obsoleteing /usr/bin/cd but
for the moment, the executable is included on AIX, SunOS,
HP-UX and SysVR4.

Sorry, but that is simply wrong. There is no way for /usr/bin/cd to influence any other process' concept of a current working directory. No shell ever invokes it for any reason ever. Change its name and see if anything breaks. All shells will simply do a chdir() to change their own cwd.

On an HP-UX 11.0 box I have just:
cd /usr/bin
mv cd xxcd
chmod 0 xxcd
Then I used lsof to insure that no process was executing xxcd or otherwise had it open. I tried sh, ksh, csh, and bash. With each shell, I tried multiple cd statements including one with no arguments. Each cd statement worked with each shell.

What is leading you to conclude that /usr/bin/cd is needed by a shell?

Nothing leads me to conclude that /usr/bin/cd is needed by
a shell. The only possible reason I can think of is that early
versions of shells did not default the argument to chdir(2).
Nowadays, this is not the case. My statement comes from the
unix man page cd(1) ...

DESCRIPTION
/usr/bin/cd
The cd utility will change the working directory of the
current shell execution environment. When invoked with no
operands, and the HOME environment variable is set to a
non-empty value, the directory named in the HOME environment
variable will become the new working directory.


So... as you can see, I didn't make this up. I'm not saying it's
necessary anymore just that is existed for some reason
and that reason is stated in the man page. In fact, all shells that
I know of (at least today) do default the chdir() argument
to whatever $HOME is set to.

I do see that language on the sun man page. Hp's man page is more rational: That language preceeds the existence of /usr/bin/cd, they should now drop the "only" from the sentence.

With HP-UX, 10.0 was the first release to have /usr/bin/cd. No earlier version of HP-UX had one.
It really is new. It was never used by any shell. There is no way to write a shell that uses /usr/bin/cd. There never was any way to write a shell that uses /usr/bin/cd in any release of any version of unix. /usr/bin/cd is virually useless.

Believe me... I do not debate the dubious value of
/usr/bin/cd. I'm only hopeing someone actually knows
why it exists. I do not believe it was a joke. The only other
possibility I can think of would be that it may act similar
to sourcing a file containing environemnt variables.
For example:

create a file called .testthis
with one line...
export HOME=/tmp

...then from your home directory do
$. .testthis
$cd
$pwd

...for the remainder of that shell session, HOME will be /tmp.
Again reasons for doing this are dubious at best but maybe
someone out there can shed some light on the reason for
having /usr/bin/cd