This article is within the scope ofWikiProject Microsoft, a collaborative effort to improve the coverage of articles relating toMicrosoft on Wikipedia. If you would like to participate, please visit the project page, where you can jointhe discussion and see a list of open tasks.MicrosoftWikipedia:WikiProject MicrosoftTemplate:WikiProject MicrosoftMicrosoft
This article is within the scope ofWikiProject Microsoft Windows, a collaborative effort to improve the coverage ofMicrosoft Windows on Wikipedia. If you would like to participate, please visit the project page, where you can jointhe discussion and see a list of open tasks.Microsoft WindowsWikipedia:WikiProject Microsoft WindowsTemplate:WikiProject Microsoft WindowsMicrosoft Windows
This article is within the scope ofWikiProject Software, a collaborative effort to improve the coverage ofsoftware on Wikipedia. If you would like to participate, please visit the project page, where you can jointhe discussion and see a list of open tasks.SoftwareWikipedia:WikiProject SoftwareTemplate:WikiProject Softwaresoftware
I thought DELTREE and XCOPY were separate programs, not internal commands? --Brion
I thought so too -- but it has been sooo long since I've played with DOS that I may be mistaken (Microsoft could have combined things later on too). -mav
Yes, DELTREE and XCOPY are external commands. They appeared about the time of MSDOS 4.0, I think (my memory is a bit fuzzy there too). XCOPY still appears in recent Windows versions, but DELTREE does not (because the 32-bit version of the command interpreter, CMD.EXE, accepts "DEL /S", making it unnecessary). --LDC, a former stormtrooper of the evil empire, now reformed. :-)
I believe DELTREE first appeared in MS-DOS 5.0. --Stephen Gilbert
I confirm. I deleted them as well as others (MOVE, COMMAND) as they are not part of COMMAND.COM.Olivier Mengué | ⇄ 22:42, 2005 May 26 (UTC)
I was thinking of adding information on how the "*" operator behaves differently in UNIX and in DOS- For example "cp *.txt *.bak" in a UNIX shell will give you a vastly different result than "copy *.txt *.bak" in DOS, primarily because the * is interpreted by the shell in UNIX, while it is delegated to the actual command binary in DOS. Should this information go here, or inMS-DOS? -DropDeadGorgias(talk) 18:19, Apr 19, 2004 (UTC)
In fact it is so much different that the shell (command.com) does'nt handle wildcards at all in MS-DOS (except for its internal commands): the shell gives the raw command line (the text as typed by the user) to the program while the Posix shells in UNIX split the command in parts, replaces wildcards with the file list… and the program receive only the pre-parsed command-line.Olivier Mengué | ⇄ 22:42, 2005 May 26 (UTC)
It should go here and incmd.exe, because this is not an MS-DOS attribute. It's an attributeof the command interpreter itself.command.com on OS/2 and on Windows NT does the same, as doescmd.exe on both of those operating systems. Other command interpreters could be written to operate differently. Note that forcmd.exe at least there's going to be a far more detailed treatment of the subject of wildcard handling atWikibooks:Guide to Windows commands.Uncle G 01:13, 2005 May 27 (UTC)
I think that this article should be named COMMAND.COM instead of Command.com/command.com because this is the real name of the program as stored in the FAT filesystem and as shown by the DIR command. If no one has objection I will move it in a few days (or months).Olivier Mengué | ⇄ 22:48, 2005 May 26 (UTC)
It's myopic to think that FAT is the only filesystem where one will findcommand.com. On OS/2,command.com might be found on an HPFS filesystem. On Windows NT,command.com might be found on an NTFS filesystem.Uncle G 01:07, 2005 May 27 (UTC)
But anyway, saying "The correct title is command.com." is incorrect. We should better say something like this: command.com can be also spelled as COMMAND.COM, as DOS filesystem is case-insensitive." Why should we write internal commands such as DIR, CD, COPY etc in capital letters and to write command.com - also a command, but an external one - in small letters?Crocodealer11:48, 6 August 2005 (UTC)[reply]
Well, personally, I wouldn't writeany of them in capital letters - you nevertype them in capital letters, after all, and MS-DOS doesn't display input auto-converted into caps. But since it seems to be an established convention to write them like that, that's fine by me. As for how it's displayed by thedir command, that would beCOMMAND COM, since IIRC the names and extensions are displayed in adjacent columns of a table format. So I see no real reason why "COMMAND.COM" is any better or worse than "command.com". -IMSoP13:56, 6 August 2005 (UTC)[reply]
Is there no variable for the current working directory? This seems to me to be so neccessary! Maybe that's just my cshell loyalty talking.—The precedingunsigned comment was added by24.213.19.99 (talk • contribs) 12:24, February 22, 2006 (UTC)
You are correct, there is no env. variable for the current working directory; however, if you want to just display the path you can issue thecd command, with no parameters; if you want to access the path use the single dot (.). —EagleOne\Talk21:41, 22 February 2006 (UTC)[reply]
In batchjobs under DR-DOS 7.02 (and higher) you could useECHOS to omit the linefeed (which would be issued byECHO) as follows:
ECHOS SET CD=> SETCD.BAT
CD >> SETCD.BAT
CALL SETCD.BAT
DEL SETCD.BAT
in order to create an environment variable named%CD% containing the current path.
Alternatively, under Multiuser DOS and DR-DOS 7.02 (and higher), various internal and external commands support a "batch" parameter/B. This can be used to modify the output of the command to become particularly suitable either as direct command line input (when redirecting it into a batch file) or as parameter for other commands (using it as input for another command). F.e., assuming the current directory would be C:\DRDOS\SYS, a commandCD /B would display:
CHDIR C:\DRDOS\SYS
instead of the usual
C:\DRDOS\SYS
so you could useCD /B > RESTDIR.BAT to create a temporary batchjob, which, when later invoked asRESTDIR.BAT, would return you back to C:\DRDOS\SYS.
Under 4DOS, you could use the internal variables%_CWD%,%_CWDS%,%_CWP%, or%_CWPS%. Windows NT COMMAND instead supports the internal variable%CD%.
If by "current working directory" you actually meant *only* the CWD, not the complete path, some versions of DR-DOS COMMAND.COM (like 7.07) can display this using thePROMPT $W or$Y tokens (in the same way as$O works as alternative to$P, the$Y token works like$W except for that it gets suppressed on floppies in order to avoid critical error messages or delays when trying to retrieve the path of a non-inserted floppy), so if you were in C:\DRDOS\SYS aPROMPT $N:$W$G would yield
C:SYS>
instead of the more familiar defaultPROMPT $P$G
C:\DRDOS\SYS>
This keeps the prompt conveniently short even when working deep inside a sub-directory tree (in particularly important when working with LFNs). On my behalf, this was added to 4DOS as well (using $W and $w there).
"although COMMAND.COM's functionality is considerably more limited than that of its Unix counterparts."
I think this shouldn't be said here. There is no actual reference comparing the two quoted here with definit conclusions. Also it is not stated which Unix counterpart it should be compared to. As COMMAND.COM was the most used command line for MS-DOS I would think a direct compare with the Bourne shell would be a good idea.
It would be rather hard to compare the two since the COMMAND.COM has a lot of commands built in where the Bourne shell heavily relies on external utilities. Even basic file operations like copying or deleting a file is done by external utilities.
More information should be added or the statement should be removed.Feel free to discuss!
There is no mention in this article about:
[b]Redirection:[/b]
command < file - replaces stdin with the contents of the file for the specified commandcommand > file - replaces stdout with the file, file is truncated if exists otherwise createdcommand >> file - replaces stdout with the file, appends if exists otherwise created
[b]Pipe:[/b]
command | command - pipes the output of the first command into the second command
[b]Devices:[/b]
CON - The console, copy con file allows you to create a file and enter the contents in the terminal (F6 finishes)LPT1 - The first LTP printer port allows for printing directly to a printer (other LPT's may be available LPT2, LPT3) or other input and output via LPT ports (can be used for communications) alias PRNCOM1 - The first COM port (RS232 port) allows for direct input or output via the COM ports, for communication or other purposes (other COM's may be available COM2, COM3, COM4)NUL - NUL outputAUX - AUX outputCLOCK$ - Clock input and output
[b]Logical Drive navigation:[/b]
A: / B: (first and second floppy drive, if no second floppy drive is available a virtual floppy drive is created allowing a user to switch between the two)other drives included hard drives, non removable drives, removable drives, ram drives and other logical drives.
[i]This is offcourse a part of the OS, but the virtual floppy is handled by the COMMAND.COM[/i]
[b]Wildcard handling:[/b]
COMMAND.COM takes care of * and ? wildcard handling, this is pretty unique.
Most if not all of this functionality is available in Linux enviroments, but it isn't integrated into the command line interpreter so I would say COMMAND.COM is one of the most powerfull command line interpreters out there.The statement about COMMAND.COM being limited compared to counterparts is clearly not correct.
I would say that it's a pretty accurate statement. COMMAND.COM has no command history, no filename completion, no aliases, no directory history, no escaping or quoting mechanism for special characters, only the most primitive of editing functions, only the most minimal conditional and flow-control mechanisms, no math or regexp support.... (And note that several of these abilities really do need to be integrated into the shell to work correctly. Unixcat doesn't suffer from being an external, while DOSKEY has fundamental limitations since it isn't part of the shell.)
Comparing DOS and Unix command shells is perhaps an unfair, apples-to-oranges comparison. But even within the much smaller set of command shells for DOS, COMMAND.COM is easily the least powerful, most limited shell in common use.
Regarding your other comments: Redirection and emulated piping are provided by COMMAND.COM, and therefore should be covered in this article. Devices like CON, COM, LPT1 and so on are implemented in DOS; I think that they would be better discussed in the DOS article. The feature of assigning two drive letters to a single floppy is also provided by DOS, not COMMAND.COM; see INT 21h .AX=440Eh and 440Fh.
It is a very accurate and relevant statement. It sounds like you have some familiarity with command.com, but very little with Unix shells. --Yath00:14, 21 August 2006 (UTC)[reply]
Is it accurate? Is it legal? If the answer to both is yes, then AFAICS it is appropriate to Wikipedia. On the other hand it would perhaps not be welcomed in WikiSource, on several grounds (original, evolving, reference material) as perthe WikiSource inclusion policy. At this point, my (newbie) opinion tends toward 'leave it'.Charles dye14:52, 24 August 2006 (UTC)[reply]
Actually, the general limit is 126 characters, as COMMAND.COM uses both a length byte and a delimiter. Under some circumstances, it is possible to go beyond that limit, but then some programs won't be able to cope with it. A detailed discussion of the limit, the reason, the implications and possible workarounds was added as a ref by me some years back. --Matthiaspaul (talk)18:50, 24 August 2017 (UTC)[reply]
The statement "The command line length in interactive mode is limited to 126 characters." is incorrect, because in MS-DOS 6.22 the maximum command length in interactive mode is 127 characters. If we want to highlight the fact that some programs may not work correctly with 127 characters, then we should say so explicitly, for example: "The maximum command length in interactive mode is 127 characters, but some/most programs require a maximum of 126 characters to operate correctly." I have changed the article to mention the maximum command length in interactive mode in MS-DOS 6.22. It would be great if you could add details about which programs may/may not work with 127 characters, since you're an expert on the issue. Thank you. — UnladenSwallow (talk)17:14, 5 February 2023 (UTC)[reply]
The "Limitations" section currently contains this statement:
It always returns a true value upon executing a command.
I don't believe that's true. For example, there's theif errorlevel command, which tests the exit status of the most recently executed code. Can someone clarify this statement? Otherwise, I think the statement should be removed. --WakingLili (talk)17:18, 28 August 2013 (UTC)[reply]
You are right, this isn't true, I have removed it. While the errorlevel can be changed also by internal commands under 4DOS/NDOS (for example, by pressing CTRL+C to abort an internal command), internal commands never change the errorlevel under COMMAND.COM, only external commands do. There is one (sort of) exception, and it only applies to DR-DOS COMMAND.COM. This implementation allows to change the errorlevel using the EXIT command, f.e. EXIT 5. By default, EXIT will return with errorlevel 0.
Things are different under CMD, but this article is about COMMAND.COM, not CMD.
I have just modified 2 external links onCOMMAND.COM. Please take a moment to reviewmy edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visitthis simple FaQ for additional information. I made the following changes:
When you have finished reviewing my changes, please set thechecked parameter below totrue orfailed to let others know (documentation at{{Sourcecheck}}).
YAn editor has reviewed this edit and fixed any errors that were found.
If you have discovered URLs which were erroneously considered dead by the bot, you can report them withthis tool.
If you found an error with any archives or the URLs themselves, you can fix them withthis tool.
I know that I am definitely talking about another article here, but the article forcmd.exe has a comparison to COMMAND.com, and I think this would be a good feature in this article. I am still not fully sure how one would go about doing this, (perhaps copying from the article for cmd,) but I thought I would share this.
YAn editor has reviewed this edit and fixed any errors that were found.
