On Linux terminals, why doesn't cd.. work?

Question

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

cd..

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

Answer 1

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 .."

Answer 2

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.

Answer 3

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...¹  It doesn’t break it into two words just because d is a letter and . isn’t (the way CMD does; see below).
______________
¹ 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.

Answer 4

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.

Answer 5

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
/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.