I was wondering while developing some application (though this is not a development question) if the cd command used in Windows is a wildcard or cross-platform command of sorts. I looked up on table with comands for Unix/Linux and MAC OS X and it turns out that it seems to be there. I am not a multi-os user, so I ask if anyone with experience in different OSes can tell me:

  1. If this command really exists and works
  2. If it has the same functionality (change directory)
  3. If there are any problems with its use
  4. If in any OS there is another command-line command that does the same in a better/more elaborate/more frequetly used way.

Thanks in advance!

(P.S.I am not 100% sure if this question belongs to this site or some other stackexchange site...)

(P.P.S Any help in tagging this will be appreciated!)

  • VMS uses SET DEFAULT instead. – user1686 Sep 30 '12 at 18:20

If this command really exists and works

Um, yes, it exists and works.

If it has the same functionality (change directory)

Yes; yes it does. That’s not to say that someone could not simply create a program (e.g., cd.exe) that does something else, but it is usually a command built into the shell and changes the current directory.

If there are any problems with its use

What kind of problems? Other than . and .., its syntax is quite straight forward. The only complication is when changing the current directory on other volumes (drive letters). Also, the command-extensions in Windows extend its usage slightly, but nothing that would cause any real problems.

If in any OS there is another command-line command that does the same in a better/more elaborate/more frequetly used way.

Not really. There can be other commands, but cd is nice and short and does the trick. Other than changing the current drive in addition to the directory, (e.g., cd /d t:\blah), how exactly could changing the current directory be improved?

This isn’t quite on-topic (though it is related), but apparently some people can’t seem to accept that the CD command does not have to be built into the shell. The fact is that it does not; it can be an external program. Some operating systems make it easy, others make it difficult, and some may even make it impossible, but the fact is that it can be external and does not always have to be built in as some would have you believe. For example, on 32-bit versions of Windows including XP and 7, you can make use of the fact that the console subsystem (which is how text-mode programs are supported and run in Windows) supports the old “DOS” interrupt 0x21—yes, even in cmd, not just `command. (It will not work in 64-bit versions of Windows because they dropped a lot of backward-compatibility.)

For example, you can save the debug script below as c.scr and compile it by running debug < c.scr from the command-line. It will create a .com file which you can use to change the current directory.

mov si,82
mov dl,[si]
or dl,20
sub dl,61
mov ah,e
int 21
mov dl,[si]
cmp dl,d
jz 119
inc si
jmp 10f
xor dl,dl
mov [si],dl
mov dx,82
mov ah,3b
int 21
mov ah,4c
int 21

n c.com

(Note, it does not support long filenames, so you will need to use the 8.3 version. It changes the current drive as well, so you can change the directory to another drive in one move, but it does this in a very simple manner and does not do any error-checking, so trying to change to a directory which starts with a letter for which a drive exists will not work. That is, c c:\windows will work as will c \windows, but c asd will not if you have an A: drive unless it happens to contain a directory named asd. You can extend it and add error-checking and such if you like, but it proves my point about the possibility of cd being external in Windows.)

You can also save the following Pascal program (e.g., as c.pas) and compile it with Turbo Pascal or the GO32 version of the FreePascal compiler (the 32-bit version won’t work because it uses the normal Windows API):

program cd;

Again, just run it to change the current directory (e.g., `c.exe "c:\program files"—yes, long foldernames will work, but will be automatically converted to 8.3 names upon execution).

  • Even though some other may put more time to write their replies, yours is most straitforward and to my points, therefore I choose this as the answer! Thanks a lot for the help! :) – Angelos Chalaris Sep 30 '12 at 20:55
  • 1
    cd must be built into the shell on both Unix/Linux and Windows systems because the current directory is part of the process state and is inherited from parent to child, not the other way. If you spawn a child process, it inherits its parent's current directory. But the child can then change its current directory without affecting the parent. This is why a separate cd.exe command would do nothing. – Nicole Hamilton Oct 1 '12 at 0:20
  • 1
    > INT 21h is an old DOS interrupt @NicoleHamilton, that is entirely beside the point. The console subsystem supports INT 21, so the statement that the cd command must be built into the shell on Windows is incorrect. – Synetech Oct 4 '12 at 16:48
  • 1
    Your c.com program only works with cmd.exe and only because cmd.exe special cases DOS children, examining the state of the NTVDM when the child exits and then setting its own current directory to match that of the child at exit. It does not work in the general case of a Win32 program starting the child with CreateProcess. I've edited your answer to add a toy program example showing that but it hasn't been made visible (yet). If for some reason my edit doesn't appear and you'd like to see it, please contact me offline. – Nicole Hamilton Oct 11 '12 at 16:20
  • 1
    @Syntech, the reason your c.com works is because the actual change directory is done by cmd.exe after it examines the NTVDM, not by the child. That's built into cmd.exe, not external. In any OS that supports a process model (do you even know what that is? It doesn't appear so!) you cannot change another process's current directory because it would make filesystem calls unreliable. A process on Windows or Linux or any other OS that supports a process model can only change its own current directory. I don't how to be more clear. – Nicole Hamilton Oct 12 '12 at 1:02

The idea of a cd change directory command was invented as part of Unix in 1969. It's terse, like most of the other Unix commands like ls, rm, sed and so on. It also matched the tree-structured filesystem invented as part of Unix, where even devices were files under /dev. It's easy to forget that before Unix, there weren't many OSes that had tree-structured filesystems with directories that ordinary users could easily create. Usually, you just got (at best) a pile of files somewhere and strange IBM utilities like IEBGENER to manipulate it.

What cd does is change the current directory of the current process, in this case, the shell, which affects how the operating system will interpret relative filenames, i.e., those that aren't fully-qualified from the root / of the filesystem. The current directory is inherited from parent to child process.

There are a couple big differences in the semantics of cd on Unix or Linux systems versus Windows systems. One is, what should cd with no operand do? On Unix or Linux, it takes you to the home directory. On Windows, cmd.exe's cd simply reports the current directory. Also, Windows is not singly-rooted, it has drive letters and you can have a current directory on each one, though the behind-the-scenes implementation is that Microsoft threw that over the wall into application space: Each process carries some hidden environment variables with strange names like =C: that the application is responsible for keeping current.

Some cd commands are better than others, but this may be a matter of taste. The C shell introduced the idea of CDPATH that works like the PATH variable does but finds directories instead of executables. The C shell also introduced directory stacks allowing you to pushd or popd the current directory. In writing my own C shell I copied all that, added an option to let the user decide what cd with no operand should do and a feature a customer suggested that if you type more than 2 dots, as in cd .... it should go up n-1 levels.


Yes, cd is a *nix command that works on Linux, OSX, and the other *nix OSes.


Just a curiosity: AFAIR, in Novell DOS (quite a few years ago) cd . remained in current directory, cd .. went to the parent directory, cd ... went two levels up in the hierarchy, cd .... three levels and so on.

  • 1
    It wasn’t just Novell DOS either, MS-DOS and the Windows command-prompt behaved like that a few versions ago as well. It’s one of the things I miss most in newer versions of Windows. – Synetech Sep 30 '12 at 19:37
  • The customer who suggested it to me, probably sometime around 1990, might well have used it in a previous shell. I know I didn't invent it. – Nicole Hamilton Sep 30 '12 at 19:37
  • @NicoleHamilton: well, it is quite an obvious idea, so it is well possible that many people invented it independently. – mbork Sep 30 '12 at 19:55

The cd command in DOS and Windows is very similar to that for Unix/Linux, and with good reason: the whole concept of directories was copied from Unix.

The first system to run MS-DOS (branded as PC-DOS) was the IBM PC. There was no hard disk — storage was on floppies, which came in 180K and 360K capacities. With such limited media, you didn't need a complicated file-naming scheme. So a fully-qualified file name was just a drive designator followed by an 8.3 filename such as a:autoexec.bat or b:advent.exe.

MS-DOS 2.0 attempted to deal with a lot of issues like this by copying features from Unix. This included directories and the commands for dealing with them. One problem was that MS-DOS was already using the / character to indicate optional arguments; this is why Windows and Unix use different path separator characters.

One important difference is that Unix has a uniform directory hierarchy with no drive designators. In adapting the cd command to MS-DOS, Microsoft had to invent new semantics for the notion of "current directory" that takes the drive designator into account. To maximize backward compatibility (so that names like a:something would still mean something sensible) they invented the notion of "current drive", and decreed that each drive have its own "current directory". So when you're changing the "current directory" you're really changing the current directory for the current drive. Usually this kind of detail isn't something you have to worrry about. But it does explain why when you're on c:\somedir and you do cd d:\otherdir nothing seems to happen. What has happened is that you've changed the current directory for you d: drive without changing your current drive; you have to enter a d: command for that to happen.

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