I think the canonical example of a "work properly" option that you always supply is in the Windows command line cd command, the "/D" option.You technically don't always need to supply it, because "cd newdir" or even "cd ..\..\path\to\newdir" work. But for some unknown reason, the command line keeps a "cd" for each drive. And so "cd S:\temp" will not change your current directory to S:\temp; it'll just mean that the next time you go "S:", your current directory will be S:\temp."cd /D S:\temp", on the other hand, actually changes your current directory. Why /D isn't the default... I can vaguely picture some trains of thought that could have led to the design, but they're all abysmal and it should never have been let out like that.
Yes, that is a good example!I don't know for sure why it's like that, but I'd have to suppose that it's some kind of a consequence of DOS's evolution from CP/M which had drive letters but not subdirectories. I bet it'll turn out something like: there was a big and important class of legacy CP/M programs that needed to be easy to port to DOS in order to make DOS sell, which expected to be able to keep opening A:THIS.DAT and B:THAT.DAT, and so if you wanted to actually take advantage of DOS's directory system to keep all the data for those programs somewhere other than the root of your drive(s) then you needed to be able to set a separate persistent cwd per drive before running the legacy program.Though I suppose even that only explains the idea of having a persistent per-drive cwd and hence some method for adjusting the directory for drive A without also making that the current drive. It still doesn't explain the bizarre idea that the default behaviour of CD A:\THING ought to be to do that specialist operation...
Back when you’d routinely use multiple floppies to keep all the files you were working on, it was not at all a specialist operation. It was pretty nice to be able to COPY A:*.* C: and have it do what you wanted because each drive had a separate working directory, without having to type so much – a bit like a two-pane file manager, without the file manager. (Remember that DOSKEY.EXE was a late addition; COMMAND.COM by itself had no command history for most of DOS standalone life, so being able to set lots of implicit state at the command line was… vital, almost. And tab completion was an even later addition, not to happen before far into the CMD.EXE era.)
COPY A:*.* C:
Note that there were several other design aspects. Because DOS itself was single-tasked, there was not a strong separation of process state, and working directories were one of these things: if you invoked a program that changed directories, upon return to the command line, you would still be in that directory – working directories were effectively only per-drive, not (at all) per-process. Along these lines, CD A:\THING not putting you on A: was quite useful, especially to batch files, which did not need to then restore the previous drive if they did not want to touch it, which was actually unreasonably hard (whereas explicitly setting it, if that was desired, was trivial).
Note also that almost all of the commands in DOS initially had no switches, and those that did, very few. Sometimes operations that you might argue to be a variation on the behaviour of existing commands were added as a separate commands, e.g. DELTREE, rather than through switches. It was all quite spartan.
To be clear, I don’t know why CD was designed this way; what I mean to say is that, as a user at the time, it seemed so obvious and sensical to me within the context of all the system’s other design choices, that I actually missed this when I first started using Unix.
(I did not understand most of this until far later, after exposure to other designs.)
Of course, it works the right way in Powershell, where CD takes you directly to any location (including network drives, lists of variables, and the registry).