hi can anyone pls tell me where is the binary for cd command stored
which cd doesnt help all it returns is the command prompt again

cd is a bash "built-in" function. (It's also, I believe, "built-in" to all other shell interpreters.) So there is no "binary" for cd to be found.

If you're looking for the source code for cd, consider looking at the source for busybox which is, in my opinion, easier to follow then the bash source.

If, for some reason, you want to change what cd does, you could, I suppose, write your own cd and "alias" it to replace the built-in functionality. (Actually, I don't know if you can over-ride a bulit in with an alias since I've never tried, but it might work.)

CD as a stand alone command is supposed to take you back to the command prompt in your home directory. "cd /etc" would take you to the command prompt in the /etc directory and cd /home/you/Documents or cd !/documents would take you to the command prompt in the Documents directory under your home directory

I beg to differ:

In Linux - or, for that matter, any computer system, there is no such thing as a "stand alone" command. There are "executable files," but they all require, at a minimum, an operating system to provide a context within which they can be run, and most also require a "shell" that manages the process of introducing the "executable" to the operating system as a candidate for execution.

Specifically, as I said above, cd is a command that is built into the shell interpreter to permit you to specify the file system "base location" to be used when referencing entries in the fie system. And, as I also said above, it has no separate executable file.

When you type, e.g., cd ~/Scripts, the shell program parses the tokens in that string, looks up the command token (cd) in it's internal table of commandqs, and then passes the remaining tokens from the input to it's internal "cd processing subroutine." If it fails to find the command in it's internal table of command, it then looks for an executable file with the specified name in the directories listed in $PATH.

On the other hand, I was not aware that cd with no arguments defaulted to cd ~/, so for that tip, thank you "john test".

Easy there. I believe "john test" meant "without arguments" when he said "as a stand alone command". A simple nomenclature problem.

Let's be clear about why the cd command must be built into the shell. We'll prove by counter-example.

If cd was not a built-in, the shell would fork/exec the "cd program" into a new (child) process. That process would then execute the chdir(2) system call. So that process' working directory would change. Then the process would exit. But no child process can affect the working directory of its parent process, or any other process for that matter. The shell's working directory would be exactly where it was before the exec'd cd command. So, what a useless program that would be!

Thus, cd must be built into the shell, implemented by a simple chdir(2) command. All sub-processes inherit the working directory of their parents, so any newly-created process has the new working directory.

Pleased to have been able to add to your store of knowledge. It is good that you were able to work your through my bad choice of words and get the the meat which was that CD with no arguments or parameters functions to take your home directory

Specifically, as I said above, cd is a command that is built into the shell interpreter to permit you to specify the file system "base location" to be used when referencing entries in the fie system.

hey cud pls xplain dis part?

The description is a little loose, not using standard terms, but the idea is correct.

Each process has a working directory, which is inherited from its parent process. The cd command changes the shell's working directory, and therefore any process started by the shell has the same working directory as the shell.

The working directory is used when relative path names are specified to various commands and system calls. Thus, if the shell's working directory is /usr/local/bin, and you type ./top, the "./" relative path component means from the current working directory. This ./top would be referring to the full path /usr/local/bin/top. The same holds true for ".." where ../../bin/mail would refer to /usr/bin/mail.

See also: Week 2 Notes, "Files, Directories, Permissions and Ownership" in Coursework at http://cis68a.mikecappella.com/ for more explanation.