Is there any reason why MS-DOS didn't use more English words to do tasks,
The most obvious one is that MS-DOS was in the beginning a rather plain CP/M clone, which itself was created with DEC systems in mind. Other, later (2.0) additions were taken from Unix. From a developer point of view it was more important to get the system running than to think about (maybe) more appealing command names.
This as well worked with early users, as they were coming with a great majority from CP/M (and some from Unix) and didn't have to relearn everything, only the newer/different features. That's way less work than learning a whole new system.
In the long run this is also quite important for international sales. While commands like
DEL are based on English words, in itself they are just a few letters to memorize. No English required. In contrast to a command like 'SHOWALLFILESONDISK' is a nonsensical bloat - and equally hard to read/learn for anyone speaking English as well.
Why couldn't the developers have made it so that I can type view insertdirectorynamehere -bare? It's a little longer to type, but it's a little clearer what exactly the code is doing.
Wouldn't that be helpful just in the early learning stage? If at all?
After all, the command line is to be used in direct dialog. Here, short easy memorable commands are king. Remember how often you screwed up typing even these short commands? Every additional letter 26-folds the chances of getting an error instead of a result.
A good CLI is always a compromise between shortness and the support of memorizing them – and regularity to cross-reference (See story below)
Insert it into a batch file that can take command line parameters and you can save yourself some typing.
Which then again would get of course a short name, to make it applicable, right? Except it would be a different short name on different machines and resulting in a real Babylon effect of no-one being able to talk to a different computer than his own - as by then, the long names used during learning phase have been vanished from memory, and guessing about name and spelling starts over.
Conclusion: Such a CLI wouldn't be forward looking.
A little mainframe anecdote to add:
In the late 1970s Siemens tried to push their mainframes (/370ish) into the mini range and targeting office applications. They invested almost more money into a creating good educational/user manuals then in downsizing the machines (*1). The basic idea was that DEC, DR or others successfully made their users use some cryptic command line, so why not use the even more complex … err … powerful BS2000 (*2) command line :) The project flopped partly due to the hardware, but equally due to the fact that the targeted users weren't doing personal computing. They used company applications and never touched a command line.
Forcing the micro/mini based concept of a command line to use separated, rather minimal applications instead of integrated software, did not only not bring the promised cost cutting, but also produced unsatisfied users. As a last effort some really nifty menu system was created. While it eased usage for first time users, it became a lump foot for more experienced ones. Several revisions of the system happened in short time until it got buried with the whole project.
So far the usual. Except (*3), the ones responsible stayed with the company, close/within OS development.
Not much later complaints about an ever growing complexity of the command line (there were function with dozens of arguments) together with increasing costs to implement new commands and/or parameters needed for new functions resulted in a project to redo the command system/interpreter. A really nifty system to structure the command interpreter as well as command and parameter modules was developed. It worked quite well and proved again, that a complete redo of something, that has been grown over years, is a great idea. Productivity of the OS development related to command execution did more than double with the new system.
Except, management (guess who *4) also came up with the idea of a way more user friendly command language. Instead of stupid pseudo language commands (and those even abbreviated), a much more clearly readable, writeable and memorizable command language should be used. And of course with way less parameters to make it easy. As handy it is, there was also a project about that at a German university on how to create such a language in a systematic way, using tools to define and handle that. So that was also brought in.
As a result, even simple things like getting the attributes of a file turned into a typing Session:
/show-file-attribues file-name=<filename> (*5)
There were many good reasons to do this, not the least the interpreter structure. Now a command and all its parameters were defined in an unambiguous way (using a DSL) that could not only be used to check for valid commands, but also take these checks out of each function into a centralized command interpreter doing all needed syntax checks before the function gets invoked, thus relieving the function program of many, many statements. The improvement on the OS development side was unprecedented. And they couldn't understand why reaction on the user side was considerable less enthusiastic. Not at all.
To be fair, they were aware that this is much to type, so the system also included a method to shorten commands to the least amount of letters needed to identify it correctly. Also, at least parameters that had to be always included (like the file name in above example) could be given without their identifier. In above case this would shorten that to:
Great, except, this is an especially simple example, and even here it doesn't work as simply, as there is also a
set-file-attribute command, so abbreviation must be rather
sh-f-a And here lies the real issue for humans. To decide which abbreviation is possible and which not, one needs to know all existing commands. There was no structure (as with MS-DOS or other hand made CLI). A human could deduct it, but it had to be learned. And relearned when new commands, conflicting with his memorized abbreviations came up.
This proved even a true bug breeder for batch-jobs. While most 'official' jobs were done with the long form, the usual quickly typed scripts did more often than not use the abbreviation its programmer preferred (*6). We have all seen these scripts not used just once, but surviving for years in production environments. Haven't we? In case of the command syntax system in use this would mean each of them could fail with any new OS release without any prior warning. Not only hard to detect and to correct, still a dangling Damocles sword over all jobs.
To make it worse, the now way longer commands made abbreviations almost mandatory. The command line is limited in length to 72 characters per line and allows only a certain amount of extension lines. With all these lengthy parameter names, this maximum was easy to reach. So not just quick and dirty procedures did sit below the sword.
Creating a file (entry) with certain attributes about devices to use, access rights and the like was originally possible within a single
FILE command, making it not just compact (and hard to read), but also atomic on the file system. Except for rather simple cases the new syntax required several different commands to first create it, then assign attributes and the like, but also several of them, as complex cases couldn't fit a single command line. All while hoping that all other processes watching the file system would be able to cope with these intermediate states that could not have happened before (*7).
Heck, it wasn't all that bad – or at least it wouldn't seem so at first sight:
The systematic command definition allowed the addition of a help screen system not just showing general messages, but giving way detailed information what is wrong with the command typed - all without any involvement of the function. These screens even allowed menu driven point and click alike completion with nicely formatted fields for all usable parameters and so on. Except, to do so the terminal was switched from line into form mode. Something a CLI user hates. Not just because of a different handling metaphor (thing about a CLI window just popping up a modal box to be handled with the mouse) destroying the flow, but also because the screen was cleared afterwards, so no easy to use of any former line to copy and reuse. Some users really developed a neurosis about not getting the help screen (*8).
Oh, and to close the circle, it also got a staircase wit: People introduced today (well, after 1990) complain a lot about the total unimaginative bureaucratic and unhandy nature of this CLI - and blame it on being typically mainframe-like complex.
Long story short: OS-development has been there and it turned out to be less than desirable.
*1 - The later resulted in what was the most unreliable and least sold of all of their mainframes, the infamous CoCo - here meaning Compact Computer, despite the fact still being the size of several table height refrigerators.
*2 - BS2000 is still around, now owned by Fujitsu. In my opinion eventually the best OS design ever. Ok, given, I should limit this to 'best internal structure and design ever'.
*3 - Which again is usual in large companies.
*4 - I don't have proof for that claim beside being told so back then. So while it sounds truth-ish, it might not be true
*5 - Looks much like the OP asked for - even more readable with hyphens separating real words, doesn't it?
*6 - It's much like the problem I mentioned in the answer about private naming conventions for batch files meant to shorten the typing.
*7 - I had one case like that in a real customer application, where one (redone) job was creating a file in a transfer directory. The complete independent (and older) transfer process did not include handling for a file with attributes set only partly the way it was expecting them. As this software was third party and a (mostly) closed system it took me quite a while to figure out a sequence to make both of us happy.
*8 - Later on it was made optional and regular error messages were displayed - but then again, instead of a simple line like
File name missing a structured analysis was presented over up to a dozend lines - again killing most of your screen.
copy... The question's pretty good, though; I can guess, but I don't actually know the answer.
DIR.BATto save yourself some typing ;)
dir /b;). I was just wondering, because in more sophisticated programming languages it's a good idea to write clean code, descriptive variable and method names, small methods. To a new comer or someone starting to maintain a system that uses batch files and cmd, they might come across
dir /band not understand it, but that's why we have the manual.