Talk:COMMAND.COM

From Wikipedia, the free encyclopedia
Jump to: navigation, search
          This article is of interest to the following WikiProjects:
WikiProject Software / Computing  (Rated Start-class, High-importance)
WikiProject icon This article is within the scope of WikiProject Software, a collaborative effort to improve the coverage of software on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 High  This article has been rated as High-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Computing (marked as Mid-importance).
 
WikiProject Microsoft / Windows (Rated Start-class, Mid-importance)
WikiProject icon This article is within the scope of WikiProject Microsoft, a collaborative effort to improve the coverage of articles relating to Microsoft on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
Start-Class article Start  This article has been rated as Start-Class on the project's quality scale.
 Mid  This article has been rated as Mid-importance on the project's importance scale.
Taskforce icon
This article is supported by WikiProject Microsoft Windows (marked as Mid-importance).
 

Error in Regard to redirection[edit]

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 (talkcontribs)

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 (talkcontribs) 19:15, 28 September 2007 (UTC)

DELTREE and XCOPY[edit]

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[edit]

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

Wildcard handling[edit]

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[edit]

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?[edit]

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[edit]

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)

No sources[edit]

"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?[edit]

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 Lenght[edit]

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)

Always returns true?[edit]

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)