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?

Community
  • 1
Josip Ivic
  • 318
  • 3
  • 8
  • 22
  • @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 '16 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 '16 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 '16 at 14:37
  • 1
    also, on that question, main role has "echo" not the difference. There's nothing about differences. – Josip Ivic Jul 19 '16 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 '16 at 14:41
  • It won't boil down to the differences. I'm just stating that this is not the same question. I've first read that one, then I asked this one. This is completley different question. It has same touching spots, but, it's different. – Josip Ivic Jul 19 '16 at 14:42
  • Look, it takes multiple close vote for this to count as a duplicate, mine alone doesn't mean anything else than my opinion. If you have anything else to add, hoping to change my personal opinion on the matter, I'd be happy to listen to your arguements in the chat. Let's both stop cluttering up the comment section. – Jarmund Jul 19 '16 at 14:44
  • Let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/42707/discussion-between-josip-ivic-and-jarmund). – Josip Ivic Jul 19 '16 at 14:44
  • @JosipIvic - Echo is used to show that there isn't any difference between the outputs, your own question indicates there is no different, I don't see how this can't be a duplicate of that question. – Ramhound Jul 19 '16 at 16:33

1 Answers1

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.

FUZxxl
  • 526
  • 1
  • 5
  • 13
  • -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 '16 at 00: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 '16 at 09: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 '16 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 '16 at 21:47
  • I might downvote if i think something is misleading e.g. suggesting that command.com is still relevant – barlop Jul 21 '16 at 21:52
  • @barlop Well then, shame on you. I'm not going to change this answer just because you think that it isn't. – FUZxxl Jul 21 '16 at 21:59
  • And aside from the fact that your post is very waffly, you wrote A)"the shell COMMAND.COM parses the command name as the longest prefix of what you typed until a space or punctuation is reached" and B)"the shell decides that cd is the command name, which happens to be a builtin command." <--- But it seems to me that 'A' is only true in the case of a built in command. If you have a file blah.exe and you do `blah,` or `blah.exe,` then the command isn't recognized. – barlop Jul 22 '16 at 11:42