Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Possible Duplicate:
Why is cd not a program?

I noticed that every other commonly used util, like ls, cp, rm, etc. are actually files in /bin -- but cd is not. Nor is it in any other binaries dir (e.g. /usr/bin, /bin, /sbin etc.).

Why is that the case?

share|improve this question
2  
you can simply use type cd –  Rahul Patil Dec 22 '12 at 5:53
add comment

marked as duplicate by jw013, manatwork, jasonwryan, Mat, jlliagre Dec 22 '12 at 8:54

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

2 Answers

up vote 5 down vote accepted

cd is a shell builtin. So it's part of the shell itself, not a separate executable.

There are basically two classes of builtin.

  • Special builtins are closely tied to the shell, and either can't be implemented independently, or aren't, because to do so wouldn't make functional sense (they are mostly to do with shell control). They are called 'special' because they have specific error handling and variable assignment semantics.
  • Regular builtins are normally implemented in the shell for performance reasons, because they manipulate shell internals (e.g. cd) or because they are technically easier that way. In some cases, a regular builtin may also exist in non-builtin form. An example of the latter case is echo, which is implemented in every modern shell, but also exists, mainly for historical reasons, as /bin/echo.

An additional reason for making critical functions builtin is that it ensures core functionality continues to remain accessible, even if something catastrophic happens to your system. For example, this could be important if shared libraries become corrupted or inaccessible, if you lost access to /bin or /sbin, or if the system becomes resource-limited in a way that disallows running further executables.

share|improve this answer
    
very good, thanks. but why is it that cd is a builtin and similar commands like ls or cp are executables ? –  amphibient Dec 22 '12 at 5:21
3  
cd doesn't actually do anything. cp copies a file from here to there, and find searches the filesystem. cd just changes what directory you are "in", which is just a notional idea for navigating in the shell. –  Andy Lester Dec 22 '12 at 5:32
    
@foampile - I've added some further explanation. –  ire_and_curses Dec 22 '12 at 5:49
    
@AndyLester Changing directory doesn't count as "doing anything"? Not sure that's entirely accurate... –  Chris Down Dec 22 '12 at 8:59
add comment

Some Unix history resources say that cd was external command at a some (quite early) period of Unix development. This was a special command which was able to modify parent's current directory.

You can see rudiments of this historical state in the fact that Solaris has /usr/bin/cd as a real command, in addition to shell builtins. But I'm unsure it does anything real in the current systems.

This being as external command was a temporary solution which was exterminated as soon as Unix developers became able to have shell builtins. It's too expensive to have a whole command (which shall have own process, be loaded from disk, etc.) in the place where simple system call is enough. So it became a builtin and, since this, didn't changed its state ever.

One could create a shell where nearly any command becomes built in; this is only a kind of design trade-off. For instance, cp mentioned here could be good candidate for this; and such building-in had been implemented in some shells for MS-DOS. But, in Unix, process creation and start is cheaper, and there is no need to invent a functionally internally unless it couldn't be implemented from another process. This includes cd, ulimit, exit, variable manipulations, control flow commands (if, for, while, etc.) and so forth.

share|improve this answer
    
There was no 'parent' in the period of unix history you are thinking of - the shell was replaced with the file you executed, and at the end it executed a new shell. –  Random832 Dec 22 '12 at 13:21
add comment

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