1

cd.. and cd ...

Basically, they are doing the same. But, who and why thought of changing it with space or without space? Why is there space and why there isn't space between cd and two dots?

C:\Windows\System32>cd..

and

[bla/www/something/something]#cd ..

They are both the same. Why one has space, and another hasn't?

EDIT:

It's not duplicate of this question:.

Why does "cd.." work in the Windows command line?

Improve this question
9
  • @Jarmund, no it isn't duplicate, I'm asking different question here. I'm asking about the difference between these two. Why is there difference, not HOW it works.
    – Josip Ivic
    Jul 19, 2016 at 14:33
  • 3
    the difference is stated in answers to the linked question, i.e. next to none. As for "Why", an answer to that would be mostly speculative, as it has not been documented anywhere and is incosistent between similar commands, which is also stated in the link answer. The question may be phrased differently, but the answer is still valid.
    – Jarmund
    Jul 19, 2016 at 14:36
  • So, can you point me where are linux terminal commands on that answer? and why is in terminal with space, and in command prompt without space?
    – Josip Ivic
    Jul 19, 2016 at 14:37
  • 1
    also, on that question, main role has "echo" not the difference. There's nothing about differences.
    – Josip Ivic
    Jul 19, 2016 at 14:38
  • 1
    An answer to that would boil down to an answer to "Why is the unix design philosophy different from that of MSDOS", which would be way too broad. Anyway, this discussion is too chatty and not very constructive. If I'm the only one who thinks it's a duplicate, that's fine by me, but my reasoning still stands, so I'll let the community decide for themselves. Either way, I hope you find your answer.
    – Jarmund
    Jul 19, 2016 at 14:41

1 Answer 1

Reset to default
1

On UNIX-like systems, the shell sh separates what you type into words and passes each word separately as an argument to the program or builtin-command referred to by the first word (the command name itself is the zeroth argument). Simplified, words are split on every space. Thus,

cd ..

is two words but

cd..

is only one. There is no command named cd.. on UNIX, thus the latter fails. The former invokes cd with the single argument .., changing one directory up. For a more complicated example,

echo foo bar  baz   quux

is parsed into the four words echo, foo, bar, baz, and quux which are then passed to the echo command as its arguments. The amount of whit espace in between is lost, and echo will print

foo bar baz quux

as it always inserts a single blank between each argument.

On Windows, DOS and CP/M, the shell COMMAND.COM parses the command name as the longest prefix of what you typed until a space or punctuation is reached (This too is a simplification). Then the command is executed with the entire line you typed as the argument. A pointer indicates where the command interpreter believes the command name ended. COMMAND.COM does not split the command line into arguments, if the program desires that to happen, it has to do so itself.

For example, in cd .. the shell decides that cd is the command name, which happens to be a builtin command. The builtin command is executed with the argument string being cd .. and the information that the first two characters form the command name. Similarly, for cd.. the shell decides that cd is the command name and passes .. as the operand name. The cd command skips the command name, trims the rest from white space and then tries to change into the directory mentioned.

Similarly for,

echo foo bar  baz   quux

the shell invokes the echo command with echo foo bar baz quux as the arguments and echo duly prints

foo bar  baz   quux

This is the reason why cd.. works in DOS but not on UNIX.

Both designs have their pros and cons, though the UNIX-style has taken over almost all systems as it is much easier to program against as only one program (the shell) needs to know how to split a command line into words as opposed to every program having its own home-cooked solution.

Improve this answer
7
  • -1 How can you answer yesterday and say On Windows, DOS and CP/M, the shell COMMAND.COM parses the command name The last Windows OS where command.com was used was Windows 98. You're about 18 years out of date in your statement about Windows. Windows XP had both cmd.exe and command.com but you were meant to use cmd.exe Windows 7 doesn't have command.com at all. And now computers are being sold with Windows 10. You don't even see anybody using Windows 98 anymore.. Some in india still use XP 'cos it requires less RAM than 7. For years, almost nobody has been using Win98.
    – barlop
    Jul 21, 2016 at 0:00
  • @barlop The mechanism is still the same in cmd.exe. Or do you think that the way a process receives its command line has changed in the last years?
    – FUZxxl
    Jul 21, 2016 at 9:51
  • There may be some minor differences in how cmd and command.com parse things msdos might not have had caret as escape character, though not relevant to cd and cd... My main point was merely the name of the file used nowadays.
    – barlop
    Jul 21, 2016 at 21:42
  • @barlop Then why do you downvote me for a minor point? Does that make my answer any less correct? Only downvote when the answer is wrong. Is my answer wrong?
    – FUZxxl
    Jul 21, 2016 at 21:47
  • I might downvote if i think something is misleading e.g. suggesting that command.com is still relevant
    – barlop
    Jul 21, 2016 at 21:52

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