In my experience, just about every single MS-DOS (and thus Windows cmd) batch file starts with the line @echo off, to silently switch off echoing of the commands in the batch file to the console. This seems unnecessarily noisy, and raises the title question: why not have echo default to off within batch scripts?

I've searched around a bit, but haven't come across anything that's directly shed light on this. It seems likely that this answer touches on some of the factors leading to this decision, but by my read doesn't answer this question directly.

The one thing I can think of emerges as a consequence of the following snip from the Microsoft docs:

  • After echo is turned off, the command prompt doesn't appear in the Command Prompt window. To display the command prompt, type echo on.

I could see it being the case that the early MS-DOS interpreters didn't have any particular way of determining the scope of the commands they were executing; in other words, they couldn't tell whether they were running directly-typed console commands or commands from a batch file, and thus the echo setting was effectively (or actually) global. Thus, since most of the time(?) users would want the prompt to be displayed at the console, echo on became the sensible default....and, from there, perhaps Microsoft just grandfathered the echo on default to retain backward compatibility? I have no idea if this actually had anything to do with it, though.

  • 16
    Showing what commands are being executed is generally a better choice than not showing - and you have to pick one. It is possible that the initial implementation was 'always show', with no choice in the matter, and subsequent complaints added the option to turn that off (via the regrettably-overloaded ECHO command). FWIW, DCL on VMS (the command language) also showed commands by default, with the ability to turn that off. This never struck me as a strange choice.
    – dave
    Commented Jun 9, 2020 at 15:13
  • 6
    It's the old rule of 'Never break a running system'. DOS 1.x did always display all lines read. So by default all later DOS should act as before.
    – Raffzahn
    Commented Jun 9, 2020 at 18:06
  • 3
    This is a case of wondering why something was done 40 years ago with 2020 eyes. Remember, this was done for the first version of MS/PC-DOS in the early 1980s. Programmers were used to 'seeing' things happen and with limited resources (in some cases 16Kb of RAM), the option to turn things on and off again sometimes just wasn't a requirement.
    – Neil
    Commented Jun 11, 2020 at 19:37
  • Oh, absolutely, @Neil -- I know my perspective is completely different now! I was interested to learn what was different then, that made this design choice sensible at that time.
    – hBy2Py
    Commented Jun 11, 2020 at 19:47

4 Answers 4


Great stuff on the the MS/PC-DOS and CP/M history in the other answers.

I'd add that batch files come from the heritage (in early DOS, CP/M, and on mainframes and other systems) of script files, intended to save the "console operator" typing and allow them to leave the "console" while the potentially time-consuming steps were being sequentially executed. The on-screen (CRT) or printed log of commands and input entered, and output generated would document what was done, and there would be no reason to hide the command input, whether typed manually or read from the script/batch file.

It is over time that elements like variables, branching, and finer control over I/O were added to scripting, turning scripts into actual programs. And so it's natural that the default continued to be what made sense for pure scripting, and deviations from that like ECHO OFF and even the @ in front of it to suppress the actual ECHO OFF have to be explicit.

  • 3
    After I asked this question here, I also pinged Rich Turner about it on Twitter. Based upon his response, this answer actually gets most closely at the original motivation for echoing commands by default (though TonyM's is a close second).
    – hBy2Py
    Commented Jun 10, 2020 at 17:01

ECHO ON was chosen as the default setting when interpreting batch files to preserve backwards compatibility. In PC-DOS 1.0, COMMAND.COM displayed each command as it interpreted it, and this couldn’t be disabled. ECHO was added in PC/MS-DOS 2.0, with a dual purpose (displaying messages, and controlling the display of batch file commands); its default is ON so that the behaviour of batch files written for DOS 1.0 doesn’t change.

As for why DOS 1.0 displayed each command as it interpreted it, a number of reasons spring to mind:

  • as john_e pointed out, CP/M 2.2 behaved in the same way, so this could be “backwards compatibility” taken a step further (or familiarity with CP/M, or any other shell with similar behaviour, driving design decisions);
  • the behaviour remains similar to that seen when entering commands one at a time — users see the prompt, the command, and whatever it outputs;
  • when using parameters, the user would see exactly how the parameters were applied, which would help understand this potentially unfamiliar new feature.

See page 3-18 of the PC-DOS 1.0 manual for an example of the latter: the manual describes a batch file, ASMFILE.BAT containing

Copy %1.MAC %2.MAC
Type %2.PRN
Type %0.BAT

and the user would then see the substitutions, as illustrated:


would show


and their results.

@ was added in version 3.3.


The choice for the default is between seeing what's going on and not seeing what's going on.

Specifically, should each command line of a batch file be shown as it's executed or not.

It seems reasonable to show them to assist in debugging, rather than hide them until you know the command in the manual that turns it on. This was in the days of reading the manual, if you had one, or asking someone who knew, if you had them to ask. No internet for further information.

In modern systems, the default is usually a 'verbose' tell-me-more mode for prompts as suchlike, with an option sometimes to select reduced/no prompts for experienced users.

  • 1
    This seems right to me (I made the same observation in a comment)
    – dave
    Commented Jun 9, 2020 at 15:14

In most cases, having commands echo to the console was harmless, and helped provide a form of progress indicator for whatever task the batch file was performing. The only times that such echo would be problematic would be when the batch file was trying to format a screen layout for itself. Having a screen look like:

A>echo Please type one of the following commands:
Please type one of the following commands:

A>echo WOOZLE -- Run the Woozle program
WOOZLE -- Run the Woozle program

A>echo FNORBLE -- Do an inventory of the Fnorbles on your system
FNORBLE -- Do an inventory of the Fnorbles on your system


Although a batch file could include messages within a batch file preceded by REM and output them with echo on, some people might have their prompt set to something that's rather long, or even has multiple lines, and trying to predict how to format things meaningfully could be difficult.

In short, having echo on by default wasn't objectionable. In fact, until the introduction of DOS 3.0 it wasn't possible to suppress the display of the first command in a batch file, so the execution of batch files that were supposed to display messages would often start with something like A>ECHO OFF, but that wasn't a particular problem.

Note that while there are some kinds of batch files that routinely start with @echo off, there were many users who ran their own batch files much more often than those from externally-produced software, and would seldom have reason to disable echo.

  • Oh, having echo on by default certainly was objectionable, in short or long :-) I used DOS daily for five years and made a lot of use of batch files for development etc. 'echo off' was always line 1, so messy otherwise.
    – TonyM
    Commented Jun 9, 2020 at 16:20
  • 1
    @TonyM: I generally leave echo on, so that if there's any problem during batch file execution I can see which command failed. I think attitudes about such things have changed in the last 35 years. Compare what one would see when booting a Windows 3.11 machine versus what one sees when booting later versions.
    – supercat
    Commented Jun 9, 2020 at 16:43
  • We used to swap files etc. and teach each other round the office and I used to help many others in a good few more company departments. I didn't know many people who liked excessive text spewing over the screen instead of just the information they need. Not sure how attitudes have changed there. You don't want to be sorting the bits a user cares about (command output) from the bits they don't. Each to their own but I think few people want a Terminator display with the 8080 assembler for what they're doing cluttering up their view :-)
    – TonyM
    Commented Jun 10, 2020 at 16:23
  • @TonyM: Compare the startup screens of older and newer versions of BIOS and Windows. Older ones would show device drivers as they were loaded, while newer versions switched to showing a Windows logo with an animation on it that gave no real clue about progress. On older systems, if one knew that the Woozle driver loaded 90% of the way through to boot process, and one glanced at a booting computer and saw that it had just loaded the Woozle driver, one would estimate how much longer the boot process would take. With the newer animation, such estimation isn't possible.
    – supercat
    Commented Jun 10, 2020 at 17:17
  • For 'batch file', are you thinking only of AUTOEXEC.BAT then? OP and I are talking about batch files far and wide in continual use. At work wrote and used throughout the day our own batch files for loading applications, performing backups, running assemblers and plenty more. I used a PC that way daily for five years, with minor use of Fixed Disk Organiser which launched batch files under a menu. I think you're talking about boot-up only, a small moment in the day, though I still had echo off.
    – TonyM
    Commented Jun 10, 2020 at 17:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .