Talk:COMMAND.COM

Error in regard to redirection

In MS-Dos Win XP version the standard error can be redirected using command 2> filename. The text states dos does not provide for this.

I am not sure if it is possible to redirect both error and stdio to a file. —Preceding unsigned comment added by 205.175.225.22 (talk • contribs)

Are you sure? I have no quick way to tell, but that looks like bash syntax. And if it is XP only, it is likely cmd.exe; this ability is documented there. — RevRagnarok ^{Talk Contrib} 22:40, 15 February 2007 (UTC)

It is possible, just use: myapp > somefile 2>&1 —Preceding unsigned comment added by Grawity (talk • contribs) 19:15, 28 September 2007 (UTC)

DELTREE and XCOPY

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)

Shortness

Obviously, saying that the shorter command is best is a bias on my part. Should we remove it? Robert Foley

Wildcard handling

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 in MS-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 in cmd.exe, because this is not an MS-DOS attribute. It's an attribute of the command interpreter itself. command.com on OS/2 and on Windows NT does the same, as does cmd.exe on both of those operating systems. Other command interpreters could be written to operate differently. Note that for cmd.exe at least there's going to be a far more detailed treatment of the subject of wildcard handling at Wikibooks:Guide to Windows commands. Uncle G 01:13, 2005 May 27 (UTC)

Name: COMMAND.COM

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 find command.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? Crocodealer 11:48, 6 August 2005 (UTC)

Well, personally, I wouldn't write any of them in capital letters - you never type 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 the dir command, that would be COMMAND  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". - IMSoP 13:56, 6 August 2005 (UTC)

I have moved the article from command.com to COMMAND.COM to make it consistent with other filenames with articles listed on Category:DOS_on_IBM_PC_compatibles (AUTOEXEC.BAT, ANSI.SYS, XCOPY, etc.) —Psychonaut 02:04, 20 September 2005 (UTC)

Turing complete?

Are batch files processed by COMMAND.COM a turing-complete programming language? If not, what are the limitations? ralmin 07:12, 21 September 2005 (UTC)

Current working directory

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 preceding unsigned comment was added by 24.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 the cd command, with no parameters; if you want to access the path use the single dot (.). — EagleOne\^Talk 21:41, 22 February 2006 (UTC)

In batchjobs under DR-DOS 7.02 (and higher) you could use ECHOS to omit the linefeed (which would be issued by ECHO) 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 command CD /B would display:

CHDIR C:\DRDOS\SYS

instead of the usual

C:\DRDOS\SYS

so you could use CD /B > RESTDIR.BAT to create a temporary batchjob, which, when later invoked as RESTDIR.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 the PROMPT $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 a PROMPT $N:$W$G would yield

C:SYS>

instead of the more familiar default PROMPT $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).

--Matthiaspaul (talk) 18:50, 24 August 2017 (UTC)

No sources

"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 command command > file - replaces stdout with the file, file is truncated if exists otherwise created command >> 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 PRN COM1 - 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 output AUX - AUX output CLOCK$ - 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.

Wtinus 03:40, 20 August 2006 (UTC)

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. Unix cat 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.

Charles dye 18:23, 20 August 2006 (UTC)

It is a very accurate and relevant statement. It sounds like you have some familiarity with command.com, but very little with Unix shells. --Yath 00:14, 21 August 2006 (UTC)

Major cleanup / tear-down?

Is this article appropriate for Wikipedia? Or has it become so much of a how-to that major chunks should be transwiki'd to WikiSource? There's a similar discussion at 4DOS... — RevRagnarok ^{Talk Contrib} 14:15, 24 August 2006 (UTC)

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 per the WikiSource inclusion policy. At this point, my (newbie) opinion tends toward 'leave it'. Charles dye 14:52, 24 August 2006 (UTC)

Command line length

The section "Limitations" reads as follows:

The command line length in interactive mode is limited to 128 characters. It always returns a true value upon executing a command.

This is wrong at least under MS-DOS 6.22, because the limit is 127 characters. --MrBurns (talk) 05:54, 30 June 2012 (UTC)

I corrected the value to 127 charakters. --MrBurns (talk) 05:55, 30 June 2012 (UTC)

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)

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)

@Matthiaspaul: (Forgot to ping you.) — UnladenSwallow (talk) 10:55, 6 February 2023 (UTC)

Always returns true?

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 the if 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)

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.

--Matthiaspaul (talk) 18:19, 28 August 2013 (UTC)

External links modified

Hello fellow Wikipedians,

I have just modified 2 external links on COMMAND.COM. Please take a moment to review my edit. If you have any questions, or need the bot to ignore the links, or the page altogether, please visit this simple FaQ for additional information. I made the following changes:

• Corrected formatting/usage for http://command.com/
• Added archive https://web.archive.org/web/20051029140802/http://www.allenware.com:80/mcsw/errorlevels.zip to http://www.allenware.com/mcsw/errorlevels.zip

When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at {{Sourcecheck}}).

Y An 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 with this tool.
• If you found an error with any archives or the URLs themselves, you can fix them with this tool.

Cheers.—InternetArchiveBot (Report bug) 08:25, 12 November 2016 (UTC)

cmd.exe article

I know that I am definitely talking about another article here, but the article for cmd.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.

Qwerty3521 (talk) 02:11, 8 May 2021 (UTC)Qwerty3521

A Commons file used on this page or its Wikidata item has been nominated for deletion

The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for deletion:

• Microsoft Windows 95 Version 4.00.1111 command.com MS-DOS Prompt 492x259.png

Participate in the deletion discussion at the nomination page. —Community Tech bot (talk) 11:09, 1 July 2021 (UTC)

A Commons file used on this page or its Wikidata item has been nominated for deletion

The following Wikimedia Commons file used on this page or its Wikidata item has been nominated for deletion:

• Microsoft Windows 95 Version 4.00.1111 command.com MS-DOS Prompt 492x259.png

Participate in the deletion discussion at the nomination page. —Community Tech bot (talk) 04:07, 27 February 2022 (UTC)

.COM file

There should be a link to COM file somewhere in this article. 217.169.17.163 (talk) 12:25, 17 May 2023 (UTC)