Create file from command line

We can create files from command line in two ways. The first way is to use fsutil command and the other way is to use echo command. If you want to write any specific data in the file then use echo command. If you are not bothered about the data in the file but just want to create a file of some specific size then you can use fsutil command.

To create file using echo

To create file using fsutil

Limitations

Fsutil can be used only by administrators. For non-admin users it throws up below error.

Thank you for the quick and dirty method since windows seems to lack the “touch” command.

How can we use these commands to ‘touch’ a file. Could anyone provide the exact command that can work as linux ‘touch’ for any type of file?

Windows does not lack “touch”. It is echo. As the post describes? type: echo “” Blah.cpp

dude, this isnt working on our school’s computers, can you tell another method that works on windows 8 computers please?

lmao it works at school PC

Make sure that you are typing in the code the right way. It happened to me when I typed in “echo This is a sample text file sample.txt”.

If you want to create a file with NO text in it do this:
at the CLI type “Echo.”: Your output should look like this:
C:\Temp>echo.

To write to a file:
C:\Temp> Echo. >test.txt

This will create a file with single space in the file.

Redirect Output from the Windows Command Line to a Text File

Avoid scrolling and/or save the generated output

One of the most useful ways to log and troubleshoot the behavior of commands or batch jobs that you run on Windows is to redirect output to a file.

However, there are a few different ways you can redirect command line writes to a file. The option you choose depends on how you want to view your command output.

How Windows Command Prompt Output Works

When you type a command in the Windows console (command prompt), the output from that command goes to two separate streams.

• STDOUT: Standard Out is where any standard responses from commands go. For example the standard response for the DIR command is a list of files inside a directory.
• STDERR: Standard Error is where any error messages go if there’s a problem with the command. For example if there aren’t any files in the directory, the DIR command will output “File Not Found” to the Standard Error stream.

You can redirect output to a file in Windows for both of these output streams.

Redirect Standard Output Write to New File

There are two ways you can redirect standard output of a command to a file. The first is to send the command output write to a new file every time you run the command.

To do this, open the command prompt and type:

The > character tells the console to output STDOUT to the file with the name you’ve provided.

When you run this command, you’ll notice that there isn’t any response in the command window except the error that the file doesn’t exist.

This is because the standard output for the command was redirected to a file called myoutput.txt. The file now exists in the same directory where you ran the command. The standard error output still displays as it normally does.

Note: Be careful to change the active directory for the command prompt before running the command. This way you’ll know where the output files are stored.

You can view the standard output that went to the file by typing “myoutput.txt” in the command window. This will open the text file in your default text file viewer. For most people, this is usually Notepad.exe.

The next time you run the same command, the previous output file will be deleted. A new output file will be recreated with the latest command’s output.

Redirect Standard Output Writes to the Same File

What if you don’t want to overwrite the same file? Another option is to use >> rather than > to redirect to an output file. In the case of this example, you would type:

You’ll see the same output (the error only).

But in this case, instead of overwriting the output file, this command appends the new output to the existing output file.

Every time you run a command and append the output to a file, it’ll write the new standard output to the end of the existing file.

Redirect Standard Error To a File

The same way you can redirect standard output writes to a file, you can also output the standard error stream to a file.

To do this, you’ll need to add 2> to the end of the command, followed by the output error file you want to create.

In this example, you’ll type the command:

This sends the standard output stream to myoutput.txt, and the standard error stream to output.err. The result is that no output stream at all gets displayed in the console window.

However, you can see the error messages by typing output.err. This will open the file in your default text file viewer.

As you can see, any error messages from the command are output to the error file. Just as with the standard output, you can use >> instead to append the error to errors from previously run commands.

Redirect All Output Writes to a Same File

All of the approaches above result in multiple files. One file is for the standard output stream and the other is for the standard error stream.

If you want to include both of these outputs to the same file, you can do that too. To do this, you just need to redirect all output to the same file using the following command.

Here’s how this command works:

• The standard output is directed to the output file identified by output number 1.
• The standard error output identified by the number 2 is redirected to the output file identified by number 1.

This will append the error output to the end of the standard output.

This is a useful way to see all output for any command in one file.

Silencing Standard or Error Output Streams

You can also turn off either Standard Output or Standard Error by redirecting the output to a NUL instead of a file.

Using the example above, if you only want Standard Output and no Standard Error at all, you can use the following command:

This will result in the same output file as the first example above where you only redirected the Standard Output, but with this command the error won’t echo inside the console. It won’t create an error log file either.

This is useful if you don’t care about any errors and don’t want them to become a nuisance.

You can perform any of the same output commands above from inside a BAT file and the output from that line will go to the output file you specify. This is a useful way to see whether any commands within a BAT file had any errors when they tried to run.

Ryan has been writing how-to and other technology-based articles online since 2007. He has a BSc degree in Electrical Engineering and he’s worked 13 years in automation engineering, 5 years in IT, and now is an Apps Engineer. Read Ryan’s Full Bio

Windows commands

All supported versions of Windows (server and client) have a set of Win32 console commands built in.

This set of documentation describes the Windows Commands you can use to automate tasks by using scripts or scripting tools.

Prerequisites

The information that is contained in this topic applies to:

• Windows Server 2019
• Windows Server (Semi-Annual Channel)
• Windows Server 2016
• Windows Server 2012 R2
• Windows Server 2012
• Windows Server 2008 R2
• Windows Server 2008
• Windows 10
• Windows 8.1

Command shell overview

The Command shell was the first shell built into Windows to automate routine tasks, like user account management or nightly backups, with batch (.bat) files. With Windows Script Host you could run more sophisticated scripts in the Command shell. For more information, see cscript or wscript. You can perform operations more efficiently by using scripts than you can by using the user interface. Scripts accept all Commands that are available at the command line.

Windows has two command shells: The Command shell and PowerShell. Each shell is a software program that provides direct communication between you and the operating system or application, providing an environment to automate IT operations.

PowerShell was designed to extend the capabilities of the Command shell to run PowerShell commands called cmdlets. Cmdlets are similar to Windows Commands but provide a more extensible scripting language. You can run Windows Commands and PowerShell cmdlets in Powershell, but the Command shell can only run Windows Commands and not PowerShell cmdlets.

For the most robust, up-to-date Windows automation, we recommend using PowerShell instead of Windows Commands or Windows Script Host for Windows automation.

You can also download and install PowerShell Core, the open source version of PowerShell.

Incorrectly editing the registry may severely damage your system. Before making the following changes to the registry, you should back up any valued data on the computer.

To enable or disable file and directory name completion in the Command shell on a computer or user logon session, run regedit.exe and set the following reg_DWOrd value:

To set the reg_DWOrd value, use the hexadecimal value of a control character for a particular function (for example, 0 9 is Tab and 0 08 is Backspace). User-specified settings take precedence over computer settings, and command-line options take precedence over registry settings.

Command-line reference A-Z

To find information about a specific command, in the following A-Z menu, click the letter that the command starts with, and then click the command name.

Writing command output in Windows cmd to a file (with a twist)

So I’m trying to run foo.exe , but I don’t want the output to the terminal but into a file. Running foo.exe > foo.txt should accomplish this for me, but it’s not. When I’m running the exe-file, I get the output. The exe is working fine in other words. However, when I try to send the output to a file, the only thing I get is this:

This only shows up when I try to send it to a file. Thinking that it could be the path (which is c:\Program Files (x86)\ and so on) which is misinterpreted, I tried specifying the output file like so: foo.exe > c:\test.txt , but still no joy.

So, aside from stating that the binary that I am trying to run is poorly written, is there anything I can do to remedy this? Keep in mind that I do get valid output when simply running the exe, it just won’t print nicely to a file. Obviously the output is there, the question is if there is some way to catch it.

1 Answer 1

You haven’t shown the command you are using that is failing. If you show it in your question, it might be easier to find a solution for you.

I expect your command is something like this:

C:\> foo.exe|c:\Program Files (x86)\something\test.txt

The error you are receiving is somewhat of a clue:

‘c:/Program’ is not recognized as an internal or external command, operable program or batch file.

First:
. is not recognized as an internal or external command, operable program or batch file.

This typically happens when you try to redirect to a file using a | instead of a > .

Second:
‘c:/Program’ .

When specifying a filename (or path) that contains spaces, you must surround it in double-quote marks ( «. « ) . This is because when the OS is determining the file to redirect to, it will stop looking for the filename when it encounters an unquoted space: «c:/Program» .

If the above doesn’t work to capture the output from foo.exe to the text file, then there is another possibility.

If the program foo.exe is writing its output to STDERR instead of STDOUT , the output of foo.exe will not be captured by using simple redirection with a single > . You would have to do it like this:

Edit:

Here is an explanation of file redirection and the 2>&1 notation.

When a program writes to the terminal, it can write to one of two Streams .

Stream 1 is referred to as STDOUT or Standard-Output. Typically, programs write their «Normal» output to stream 1.

Stream 2 is referred to as STDERR or Standard-Error. Typically, programs write their «Error» output (error and warning messages) to stream 2.

Whether a program writes a particular output to STDOUT or STDERR is determined by the programmer and how they wrote the program. Some programs are written to send all output (normal output and errors) to STDOUT .

When a program is run with no output redirection, all normal and error output is sent to the terminal screen without any distinction between what is STDOUT output or STDERR output.

When you do «normal» redirection with a single > like this:

you are not specifying which Stream is being redirected to the file, so Stream 1 is assumed.

It’s the same as if you typed it like this:

This tells the command interpreter ( cmd.exe ) to capture the program output for STDOUT (Stream 1) to the specified filename. The 1 in 1> refers to Stream 1.

In this case all the normal program is captured to the file, but if the program writes to STDERR (Stream 2), that output will not be captured and will be shown on the screen. This is generally the «desired» way to do it so that while you are capturing the normal program output, you can see on the screen if an error occurs.

If you want to capture «Normal» output to one file, and «Error» output to a different file you can do it like this:

If you want the «Normal» output and the «Error» output to be captured to the same file, you can specify it like this:

This is basically a «shorthand» way of specifying it and it means to redirect Stream 1 to the specified file, and to also redirect Stream 2 to the same «place» (file) as Stream 1.
Edit:

Is there any difference between foo.exe > «c:\output.txt» 2>&1 and foo.exe > «c:\output.txt» 2>»c:\output.txt»? Are they identical?

Short answer: You would think they are identical, but no. They are different.

With redirection using >»filename.ext» , 1>»filename.ext» , or 2>»filename.ext» , the > causes the output to be written to a new file named «filename.ext». If the file «filename.ext» already exists, it will be deleted first.

foo.exe > «c:\output.txt» 2>»c:\output.txt»

causes a «conflict» where both redirections are trying to write to the same file and both are trying to delete the file if it already exists. This will likely cause undesired behavior. Generally, one or the other, or both, of the outputs will NOT be captured fully, or predictably.

The actual result will depend on the operating system and version, and may also depend on the command being executed. What will likely happen is:

1 The output sent to one of the redirections will be captured or partially captured, and the output sent to other redirection will be lost. 2 The operating system will complain about the command and neither of the outputs will be captured (fully). 3 Undefined, undesired, unpredictable, unexpected behavior.

On Windows 7 and likely on Windows Vista/8/10, and possibly on Windows XP, the operating system will complain about command and the command will be canceled.

For example (Windows 7): I have a folder named: «C:\Temp\emptyfolder» and a file named «nonexistantfile» doesn’t exist there.

In this case, using one redirection ( >output.txt ), the output of the dir command is captured the the file: output.txt , and the error message File Not Found is shown on the screen. this is the expected behavior.

Now, using both redirections («>file» AND «2>file»):

In this case, the operating system complained that the (outout) file is already in use. And the file «output.txt» ends up empty (0 bytes), and the output for both of the redirections was lost.

Now, lastly, using both redirections («>file» AND «2>&1»):

In this case, «>file» causes the output for «stream 1» («standard output») to be captured to the file. And «2>&1» causes the output for «stream 2» («error output») to be sent through the already redirected «stream 1», and to also be captured to the (same) file.

It is also worth noting that the order is important. Reversing the order like this:

is not the same and will probably not give you the desired result.

In this case, «2>&1», which is seen and precessed first, causes the output for «stream 2» («error output») to be redirected to the place where «stream 1» is currently directed to, which at that moment, is (by default), the screen. And «>file» causes the output for «stream 1» («standard output») to be captured to the file. The end result, is that the output of the command («stream 1») will be captured to the file, but the error output («stream 2»), will still go to the screen (not to the file).