cmd-Difference between quit and exit

If you type telnet in cmd, you will have to type quit to get out of there, but if you type wmic, both quit and exit will work.

Welcome to Microsoft Telnet Client
Escape Character is 'CTRL+]'
Microsoft Telnet> exit
Invalid Command. type ?/help for help
Microsoft Telnet> quit
C:\windows\system32>

C:\windows\system32>wmic
wmic:root\cli>quit
C:\windows\system32>
C:\windows\system32>wmic
wmic:root\cli>exit
C:\windows\system32>

Also, Ctrl+C is supposed to abort a running process or terminate a batch job but Ctrl+C will also exit from wmic but not telnet.

What is the need of all this confusion? Why can't there be just one standard??

3 Answers

The reason for this is that the applications are separate. Telnet launches the telnet.exe program in your terminal and everything you type happens within telnet.exe and NOT within cmd.exe (your command prompt) Your command prompt just became the interface with which you send telnet commands to telnet.

wmic.exe is a separate program with it's own set of commands it may have a different exit command than other programs. You can look in to the list of commands for each program you run within command prompt and there are some standards but they aren't 'by necessity'.

If you were to launch a python session inside of command prompt your ctrl+c would break a python activity but exit() would be the command to run to exit.

Let me know if you need more explanation than this, it's basically just that each program (telnet.exe, nslookup.exe, wmic.exe) has it's own unique set of commands and they are not always standardized because different developer or teams or changes over time have been involved with each program.

As noted in a comment above, telnet is also an older standardized service used by many vendors whereas wmic is a Microsoft developed product, this is another thing to consider when looking at standardized commands - For example it would be more likely that Microsoft developed tools (wmic, etc) have standardized commands while cross platform tools (telnet, ssh, etc) behave the same across platforms (Mac, *nix, Windows) but not in accordance with Apple developed or Microsoft developed common/best practices.

Here are the Docs from Windows SDK. As to the Why, so programs can tailor how they work Ctrl + C is also character code 3 which is control code etx - end of text. Also remember CMD is just an ordinary console program, like wmic or ftp.

Console Control Handlers

Each console process has its own list of control handler functions that are called by the system when the process receives a CTRL+C, CTRL+BREAK, or CTRL+CLOSE signal. Initially, the list of control handlers for each process contains only a default handler function that calls the ExitProcess function. A console process can add or remove additional HandlerRoutine functions by calling the SetConsoleCtrlHandler function. This function does not affect the lists of control handlers for other processes. When a console process receives any of the control signals, it calls the handler functions on a last-registered, first-called basis until one of the handlers returns TRUE. If none of the handlers returns TRUE, the default handler is called.

The function's dwCtrlType parameter identifies which control signal was received, and the return value indicates whether the signal was handled.

For an example of a control handler function, see Registering a Control Handler Function.

CTRL+C and CTRL+BREAK Signals

The CTRL+C and CTRL+BREAK key combinations receive special handling by console processes. By default, when a console window has the keyboard focus, CTRL+C or CTRL+BREAK is treated as a signal (SIGINT or SIGBREAK) and not as keyboard input. By default, these signals are passed to all console processes that are attached to the console. (Detached processes are not affected.) The system creates a new thread in each client process to handle the event. The thread raises an exception if the process is being debugged. The debugger can handle the exception or continue the exception unhandled.

CTRL+BREAK is always treated as a signal, but an application can change the default CTRL+C behavior in two ways that prevent the handler functions from being called:

The SetConsoleMode function can disable the ENABLE_PROCESSED_INPUT input mode for a console's input buffer, so CTRL+C is reported as keyboard input rather than as a signal.

When SetConsoleCtrlHandler is called with NULL and TRUE values for its parameters, the calling process ignores CTRL+C signals. Normal CTRL+C processing is restored by calling SetConsoleCtrlHandler with NULL and FALSE values. This attribute of ignoring or not ignoring CTRL+C signals is inherited by child processes, but it can be enabled or disabled by any process without affecting existing processes.

CTRL+CLOSE Signal

The system generates a CTRL+CLOSE signal when the user closes a console. All processes attached to the console receive the signal, giving each process an opportunity to clean up before termination. When a process receives this signal, the handler function can take one of the following actions after performing any cleanup operations:

Call ExitProcess to terminate the process.

Return FALSE. If none of the registered handler functions returns TRUE, the default handler terminates the process.

Return TRUE. In this case, no other handler functions are called, and a pop-up dialog box asks the user whether to terminate the process. If the user chooses not to terminate the process, the system does not close the console until the process finally terminates.

Send comments about this topic to Microsoft

Build date: 10/2/2006

All quit, q exit from telnet shell.

Both exit and quit exit from wmic shell.

exit exits from cmd.exe, that is Windows Command Prompt shell.

So, it depends where you are and what you're quitting from as shells[as in, interactive programs accepting commands], have their own commands.