On Windows/DOS terminals a cd.. correctly change the directory.

On Linux terminals the dots from the cd command have to be separated. I'd like to know how/why is this necessary for the parser to work. If no space is added then the command is not understood.

This works well

 cd ..

This does not work


Probably the regExp or whatever is parsing the commands is not including the dot as a possible character immediately after the command.

  • 2
    Same as the difference between my-random-command and my-random-command..
    – muru
    Jul 8, 2019 at 15:18
  • 2
    Many of the answers are wrong about command and cmd, fundamentally wrong in a few of them. As I wrote in a comment to one, Unix and Linux is really not the place for a full explanation of these programs. The question is wrong, too, inasmuch as "well" is not the word to use here. I am on record on the subject elsewhere, as is Rex Conn. Given that IBM and Microsoft tacitly discouraged this syntax, with the railway diagrams in the OS/2 doco for cmd not permitting it, it seems likely that no author of command, cmd, or a replacement for the same would say "well" here.
    – JdeBP
    Feb 5, 2020 at 9:58
  • 2
    And we wouldn't call them "terminals", either. They are command processors, that use consoles (that name from Win32, but the I/O architecture predating it). jdebp.uk./FGA/tui-console-and-terminal-paradigms.html jdebp.uk./FGA/a-command-interpreter-is-not-a-console.html superuser.com/a/329479/38062
    – JdeBP
    Feb 5, 2020 at 10:03

5 Answers 5


The normal syntax is cd ... The Windows command interpreter is a bit more flexible and accepts cd.. as well.

When you use cd.. the shell tries to find a command or program named exactly cd..

To make your bash accept the command cd.. you can define an alias:

alias cd..="cd .."
  • 2
    or easier shopt -s autocd, and then type ..
    – pLumo
    Jul 8, 2019 at 15:24
  • iirc, windows also lets you do cd... instead of cd ../.. it takes a second to get used to that when making the windows to linux switch.
    – jhufford
    Jul 8, 2019 at 22:13
  • 1
    computerhope.com/cdhlp.htm says that you can do cd... on Win95 and later, so maybe my recollection wasn't completely wrong. I guess I don't know to what versions that applies.
    – jhufford
    Jul 8, 2019 at 23:13
  • 1
    The Windows command interpreter is a bit more flexible and consequently not compatible with POSIX.
    – user232326
    Jul 17, 2019 at 22:18

There is no real difference. The Windows CMD shell decided to accommodate the typo, whereas Linux's shells are more strict about separating the command or program (in this case the shell's built-in cd) from the argument.

  • 1
    How do you know they "decided to accommodate the typo"? How do you know they even considered it a typo to begin with, instead of just deciding to define the command or the parsing in a different way?
    – ilkkachu
    Jul 16, 2019 at 15:16
  • 1
    @ilkkachu Whoever they are decided to accept cd.. as a command equivalent to the pre-existing Unix command cd ... Without knowing who the primary actors were we really cannot discern their motives. We do know that a pre-existing command was modified and accepted as valid in the Windows environment.
    – doneal24
    Jul 17, 2019 at 21:59
  • @doneal24, well, I think the fact that you had to explicitly mention Unix command is rather relevant here. It's not like DOS was directly based on Unix, and the command line is different enough that I wouldn't assume they had the same goals or definitions as Unixes to begin with. Now, if we looked at how CP/M or such did it, and why, that just might be interesting.
    – ilkkachu
    Jul 18, 2019 at 6:03
  • 1
    @ilkkachu Looking at CP/M might not return much help. CP/M 2.2 did not support subdirectories, hence no need for a cd command.
    – doneal24
    Jul 18, 2019 at 12:35
  • @doneal24, ah, right.
    – ilkkachu
    Jul 18, 2019 at 16:26

Why doesn’t cd.. work in Unix & Linux?

Unix shells treat a lot of non-alphanumeric characters (e.g., @_+-{}:,./~) as if they were letters, so you could have commands called a@, b_, c+, d-, etc.  So when the shell sees cd.., it treats it as a four-letter word, no different from cdef or cd56, and so it looks for a command called cd...1  It doesn’t break it into two words just because d is a letter and . isn’t (the way CMD does; see below).
1 As pointed out by Bodo, you can define an alias (or a shell function (or a shell script)) called cd...  Of course it’s probably a bad idea to write a shell script called cd.. (or cdanything), because a shell script can’t cause the shell that calls it to change directory.

Why does cd.. work in CMD?

The rules for how CMD parses commands seem to be complex and not well documented.

  • Wikibooks says:

    The parsing of a command line into a sequence of commands is complex, and varies subtly from command interpreter to command interpreter.

  • David Deley says that, in Windows, “Everyone Parses Differently”:

    You'll get different results if you pass a command line to ShowParams.exe (written in C/C++), ShowParams.vbs (VBScript), or ShowParams.bat (batch file)…

  • How does the Windows Command Interpreter (CMD.EXE) parse scripts? (on Stack Overflow) contains extensive, detailed answers to the titular question.

… but (in about an hour’s worth of searching) I couldn’t find anything that specifically addresses this issue of how CMD determines what the command is (i.e., what we would call argv[0] in a C program in Unix).

I’ve done some testing / experimentation (on Windows 7).  One pattern I’ve observed is that, after a first tokenization pass (breaking the command line at spaces and high-precedence characters like <, >, &, |, , and /), CMD looks at the first word on the command line, and breaks it apart at certain other non-alphanumeric characters (including ., +, =, and \).

  • If the word up to the first such non-alphanumeric character is a builtin command that doesn’t take arguments, then that command is executed.  For example, cls., cls.., cls.abc, cls.a.b.c, cls.exe, cls=, cls=abc, cls+, cls+abc, cls\, cls\abc, and many more variations, act like just plain cls and clear the screen.  Ditto for pause.

    These seem, at first, to be exceptions to the above:

    • cls/ and cls/a/b/c give an error message.
    • cls/? gives a help message.
    • pause/ and pause/a/b/c simply pause (i.e., they act like just plain pause).
    • pause/? gives a help message, says “Press any key to continue . . .”, but doesn’t wait for you to press a key.  (This is a bug.)

    But the above are consistent with the idea that CMD breaks things into tokens at / characters.  cls/ behaves the same as cls /, for example.

  • echo is special case:
    • echo on turns the echo on.
    • echo off turns the echo off.
    • Just plain echo reports the state of the echo flag.
    • But, if echo is immediately followed by a non-alphanumeric character (like ,, . or /), then that character is ignored, but special processing for the rest of the command gets disabled.  So, if you want to print the word “on” or “off”, use echo.on or echo.off, and, to print a blank line, use echo..  And so echo.. acts like echo . [sic].
  • TL;DR
    In other cases, CMD seems to look up to the last dot (or group of dots), and if that substring is a builtin command, it interprets it as that builtin command.  So cd.., dir.., type..\filename.txt and copy..\filename newname all act like there was a space before the first dot. 

But this works only for builtins; for example, calc.. and find.. get the “… is not recognized as an internal or external command, operable program or batch file.” error.  So, for some fun examples:

  • If you have a program called abcd.efg.exe, you can run it by typing abcd.efg.  But if it’s called cd.efg.exe, then cd.efg fails, because it’s parsed as cd .efg.  You would have to type cd.efg.exe.
  • Similarly, if you have a subdirectory called abcd in the current directory, and a program called efg.exe in that subdirectory, you can run it by typing abcd\efg.  But if the subdirectory is called cd, then cd\efg fails, because it’s parsed as cd \efg.  You would have to type cd\efg.exe.
  • 1
    In general, the attempt to interpret .,.. and `` is rooted in the intent to process windows paths (which might include spaces and could be relative (../path)).
    – user232326
    Jul 17, 2019 at 22:24
  • 1
    Possibly the two foremost experts on this, outwith the IBM and Microsoft authors, are Rex Conn, author of 4DOS, and me, author of a replacement CMD for OS/2. M. Conn is famously on record on the subject, and I am on record as favouring what the IBM railway diagrams in the OS/2 doco say. We've both written on the subject over the years. I specifically described some of the quirks, including the one at hand, in the doco that accompanied my CMD. M. Conn has a number of web log entries on the subject. This answer does not really describe things correctly. But Unix and Linux is not the place.
    – JdeBP
    Feb 5, 2020 at 9:27
  • @JdeBP: Yes, I agree that this question would have made more sense on Super User. I posted this answer because (1) none of the other answers had (IMO) properly addressed the Unix side of the question, (2) none of the other answers had (IMO) come close to getting the CMD side of the question right, (3) the OP asked me to post my observations as an answer, and (4)  Kusalananda also seemed to encourage me to do so.  As I said, I did only about an hour’s worth of concentrated research (to supplement decades of casual observation), so I’m not surprised that you grok the subject better than I. Feb 6, 2020 at 7:22
  • And now I’m curious to learn what you and M. Conn have written, but I’m too lazy to use Google.    :-)    Why not provide some links?   And what are ‘‘IBM railway diagrams’’? Feb 6, 2020 at 7:22

On Linux terminals we have to separate the dots from the cd command. I'd like to know how/why is this necessary for the parser to work.

Probably the regExp or whatever is parsing the commands is not including the dot as a possible character immediately after the command.

Yes, in a sense. Shells (well, at least POSIX ones) treat . as a regular character, just like letters and digits. Some other characters have special meanings (when unquoted), like ;, <, ( etc. Whitespace and some special characters can be used to split the command into words.

Considering that directories and filenames can contain dots (and especially the fact that .. is a common directory name), it's a good idea for the command line parser to treat the dot as a regular character. Otherwise, how would a command like ../foo.sh some args work? Would the first part get split between the o and the dot? Or already between the dot and the slash?

Allowing a command like cd.. to be treated like cd .. would likely require a bunch of special cases, which would make the implementation awkward and confuse users. It's far simpler to just split at the whitespace, and then take the first word as the command (regardless of if it's a builtin, a function, or an external command). It's not strictly necessary, it just seems simpler than the alternative.

  • 1
    No, not only whitespace works to split command line into words. Any redirection or control operator (in Posix) or any metacharacter (in ksh, bash, etc) works to delimit a word.
    – user232326
    Jul 17, 2019 at 21:58
  • @Isaac, yeah, you're right. I ignored special characters since most of them will just terminate the command, too (so you don't get any useful words after that). ; ends the command, ( causes a syntax error, and I stopped thinking there. Redirections would indeed work, echo<foo bar results in the two "arguments" echo and bar (I can't remember what the first word that ends up as the command name is called.) I edited that, even though it muddies the idea a bit.
    – ilkkachu
    Jul 18, 2019 at 5:58
  • The unstated right answer actually addresses the "regExp or whatever" in the question. Shells have formal grammars, with lexemes, and their lexing is the fundamental thing here.
    – JdeBP
    Feb 5, 2020 at 10:10
  • @JdeBP, well, the grammar could be defined so that cd.. splits into two tokens, in the same way cd .. does. But that would seem to imply more complexity in the rules, or special cases to make it work. Anyway, go ahead and edit you feel there's need to mention something more explicitly.
    – ilkkachu
    Feb 5, 2020 at 12:07

cd in Windows is an internal command and you cannot find it as an executable in windows.

Here is a list of internal DOS commands.

Whereas cd in a Linux system is an actual program which you can find in /bin.

[root@localhost j]# ls /bin/cd

And it can only take arguments with space, because when you do cd or anycommand followed by few args, the bash looks for the first thing you typed in the $PATH env variable which is probably set to /usr/bin, executes the program and feeds anything you typed later as args. When you type cd.. the bash will look exactly for cd.. under /usr/bin and gives you an error as it cannot find such program.

This is a simply better design.

  • 5
    There is an external command for cd, but that's not what you're executing when you run cd
    – muru
    Jul 8, 2019 at 15:16
  • 2
    Not all Linuxes have /bin/cd//usr/bin/cd, e.g. none of my Debian's do. Even if it does exist, and you run it, it won't do what you want.
    – ilkkachu
    Jul 8, 2019 at 16:37
  • @ilkkachu, what do you mean by "it won't do what you want"?
    – Vignesh SP
    Jul 8, 2019 at 22:23
  • 3
    Since an external command like /bin/cd is run in a separate process, and the current dir is a per-process attribute, running the external cd won't change the current dir in the calling shell. The external cd can only be used to check if a directory could be chdir into.
    – user313992
    Jul 8, 2019 at 23:11
  • 1
    You’re comparing apples and oranges. In Windows, mkdir..\newdirectory does work. Jul 17, 2019 at 19:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .