Can somebody remember what was the command to create an empty file in MSDOS using BAT file?
copy NUL EmptyFile.txt
DOS has a few special files (devices, actually) that exist in every directory, NUL being the equivalent of UNIX's /dev/null: it's a magic file that's always empty and throws away anything you write to it. Here's a list of some others; CON is occasionally useful as well.
To avoid having any output at all, you can use
copy /y NUL EmptyFile.txt >NUL
/y prevents copy from asking a question you can't see when output goes to NUL.
echo. 2>EmptyFile.txt
This redirects output stream 2 (stderr) to a file. The command echo doesn't output anything to stderr, so the file becomes empty.
Plain echo would work too, but echo. is better because it doesn't print the useless and potentially confusing message ECHO is on.
type NUL > EmptyFile.txt
After reading the previous two posts, this blend of the two is what I came up with. It seems a little cleaner. There is no need to worry about redirecting the "1 file(s) copied." message to NUL, like the previous post does, and it looks nice next to the ECHO OutputLineFromLoop >> Emptyfile.txt that will usually follow in a batch file.
Techniques I gathered from other answers:
Makes a 0 byte file a very clear, backward-compatible way:
type nul >EmptyFile.txt
idea via: anonymous, Danny Backett, possibly others, myself inspired by JdeBP's work
A 0 byte file another way, it's backward-compatible-looking:
REM. >EmptyFile.txt
idea via: Johannes
A 0 byte file 3rd way backward-compatible-looking, too:
echo. 2>EmptyFile.txt
idea via: TheSmurf
A 0 byte file the systematic way probably available since Windows 2000:
fsutil file createnew EmptyFile.txt 0
idea via: Emm
A 0 bytes file overwriting readonly files
ATTRIB -R filename.ext>NUL
(CD.>filename.ext)2>NUL
idea via: copyitright
A single newline (2 bytes: 0x0D 0x0A in hex notation, alternatively written as \r\n):
echo.>AlmostEmptyFile.txt
Note: no space between echo, . and >.
idea via: How can you echo a newline in batch files?
edit It seems that any invalid command redirected to a file would create an empty file. heh, a feature!
compatibility: uknown
TheInvisibleFeature <nul >EmptyFile.txt
A 0 bytes file: invalid command/ with a random name (compatibility: uknown):
%RANDOM%-%TIME:~6,5% <nul >EmptyFile.txt
via: great source for random by Hung Huynh
edit 2 Andriy M points out the probably most amusing/provoking way to achieve this via invalid command
A 0 bytes file: invalid command/ the funky way (compatibility: unknown)
*>EmptyFile.txt
idea via: Andriy M
A 0 bytes file 4th-coming way:
break > file.txt
idea via: foxidrive thanks to comment of Double Gras!
REM. > empty.file
If there's a possibility that the to be written file already exists and is read only, use the following code:
ATTRIB -R filename.ext
CD .>filename.ext
If no file exists, simply do:
CD .>filename.ext
(updated/changed code according to DodgyCodeException's comment)
To supress any errors that may arise:
ATTRIB -R filename.ext>NUL
(CD .>filename.ext)2>NUL
One more to add to the books - short and sweet to type.
break>file.txt
break>"file with spaces in name.txt"
fsutil file createnew file.cmd 0
You can use a TYPE command instead of COPY. Try this:
TYPE File1.txt>File2.txt
Where File1.txt is empty.
There are infinite approaches.
Commands that output nothing:
break
cls
color
goto
pushd
popd
prompt
title
Weird Commands:
CD.
REM.
#echo off
cmd /c
START >FILE
The outdated print command produces a blank file:
print /d:EMPTY_TEXT_FILE nul
You can also use SET to create a null byte file as follows
set x=x > EmptyFile.txt
Or if you don't want to create an extra variable reassign an existing variable like
set PROMPT=%PROMPT% > EmptyFile.txt
or like this:
set "PROMPT=%PROMPT%" > EmptyFile.txt
The easiest way is:
echo. > Filename.txt
IMPORTANT:
If you don't set the encoding, many softwares can break. git is a very popular example.
Set-Content "your_ignore_file.txt" .gitignore -Encoding utf8 this is case-sensitive and forces utf8 encoding!
Related
I have a file (let's call it version.txt) that contains a version number and some text:
v5.02
Some text explaining
where and how this
number is used
Based on this answer, I use
set /p version=<version.txt
to store the first line of the file in the version variable. Now I'm trying to write a batch script that operates on folders that contain this version number in their name. However, I get unexpected results because something seems to go wrong when I insert the variable in a path. For example, this script
#set /p version=<version.txt
#echo C:\some\folder\%version%\some\file.exe
prints
C:\some\folder\v5.02
instead of
C:\some\folder\v5.02\some\file.exe
What's going on? I have a feeling there are hidden characters of some sort at the end of the text in the variable, because setting the variable by hand to a constant in the script works.
Edit: I'm using Windows 10 with Notepad++ as my editor, if it helps.
I can only replicate your issue, when version.txt uses Unix line endings (LF) instead of Windows (CRLF). for /f is immune to this issue:
for /f "delims=" %%a in (version.txt) do set "verion=%%a" & goto :skip
:skip
echo C:\some\folder\%version%\some\file.exe
goto :skip breaks the loop after reading the first line.
Since everything I tried didn't seem to work, the solution I found in the end is to call the batch script from a Python script. The Python script reads the first line of the version file and passes it as an argument to the batch script. Out of context, it is a bit of an inelegant solution, but in my case the batch script was already called by a Python script, so it's not that terrible.
Here is a minimal example:
version.txt
v5.02
Some text explaining
where and how this
number is used
script.bat
#echo C:\some\folder\release\%1\some\file.exe
script.py
import os
with open("version.txt") as f:
version = f.readline().rstrip()
os.system("cmd /c script.bat %s" % version)
Edit: Following Stephan's comment, I tried to change the line ending in the text file from LF to CRLF and it indeed solves the problem. However, since I don't really have control over everything that writes in that file, the solution above remains the most feasible in my case.
Edit 2: Stephan's answer (with the for loop) is actually a better solution than this one since it avoids having to transfer part of the work to the calling Python script.
So, when I'm echoing text from a batch file to a text file, I can escape the special characters without issue. However, when I echo a certain character combination, I can't seem to find a way around the fact that it is just echoing to the screen and not to the file.
Here's what works...
echo firsttest^=uncpath>>test.txt
echo [secondtest]>>test.txt
Here's what doesn't work...
echo thirdtest^=1>>test.txt
echo fourthtest^=2>>test.txt
I've tried escaping one and both of the arrow characters, but still no-go.
Any advice? I'm sure it has to do with the standard redirection of console output using the "1>" and the "2>", but just don't know how to get around that.
Thanx.
Your analysis is correct. There are two main concepts to work around it:
(echo thirdtest=1)>>test.txt
(echo fourthtest=2)>>test.txt
and
>>test.txt echo thirdtest=1
>>test.txt echo fourthtest=2
(Note: = isn't one of the special characters that need escaping)
Where in the line you put your redirection doesn't matter, as running with echo on shows. (if you enjoy to get confused, enter echo hello>file.txt world, followed by type file.txt)
Another note: if you echo several lines, it's faster to:
(
echo first line
echo second line
echo third line
)>>test.txt
(reason: needs only one disk access (read/modify/write) instead of doing the same for each single line) You won't notice it with just three lines, but think of writing hundreds of lines (for example in a loop). Time savings will be huge.
I have a batch file with the following code within:
ECHO .> C:\file.txt
I read about ECHO and understand what it is used for, but what I do not know is what are the characters used for after the word echo (.>) and what is the use of the path of file after that.
It's used to truncate, or create if necessary, the file. echo . outputs a single line which is redirected to the file, effectively truncating it.
To obtain an absolutely empty file I often use cd . > filename. I don't know where I picked that one up but it's been around for a long time on UNIX systems.
> redirects the output of the command before.
echo .>c:\file.txtprints a dot to the file c:\file.txt, overwriting its contents (so it will contain a dot only afterwards)
I think, you got it wrong. Usually echo.>file.txt is used to create a empty file (or delete the contents, if the file exists). (Note the missing space)
Is there a way to convert all CRs to CRLFs in a text file?
When I open a text file from Linux server on Windows, all text is displayed in one line, but actually it's a multi line one.
I'd like to perform the conversion in a batch file.
Can anyone advice, please?
Line separators and line terminators have been a source of compatibility friction between systems as long as there has been more than one kind of system and an urge to exchange data. The Wikipedia article on the Newline has a decent overview of the historical context. And, it suggests a variety of solutions to this problem specifically for use on the Unix side or the Windows side.
On the Unix (Linux) side, look for a utility named unix2dos and its close relative dos2unix. These are commonly available, either as a component of a commercial Unix or as open source tools. If available, they are the best answer because they (usually, see your verson's man pages for details) are careful about files that are accidentally written with both line endings. In that unfortunate case, a trip through both utilities will usually clean up the file to be internally consistent. In the absence of these convenient commands, many native utilities can be made to do the conversion. For instance, converting DOS CRLF line endings to Unix newlines can be done with the tr command:
$ tr -d '\r' < inputfile > outputfile
But do note the caveat that this command assumed that all lines were terminated by CRLF (or LFCR) and works by simply deleting every CR character from the input. Any naked CR characters will be lost.
On the DOS and Windows side, it used to be a lot bleaker. Ports of unix2dos and dos2unix certainly exist, for instance they are included in the much larger Cygwin tools that provide a complete unix emulation on a Windows machine. But a solution using only built-in features was hard to find.
Modern Windows (probably since Windows XP), however, is better. There, the built-in FIND command is much less touchy about choice of line terminator than it used to be, and can be used to do the required conversion from Unix line endings to DOS endings. The Wiki page cited above gives this recipe:
C:\...> TYPE filename.u | FIND "" /V >filename.txt
Experimentation shows that this works as well, but it may not give identical results for unknown reasons:
C:\...> FIND "" /V <filename.u >filename.txt
In both cases, you create a copy of the file with the changed line endings. It would probably not be recommended to change the files in place.
I'll mention one other approach that always seems tempting on paper. When you use Samba to provide the file system share on the Linux server for mounting by Windows, there is a configuration option you can set for the share that mounts it in "text mode". Shares mounted in "text mode" automatically have line endings converted. If it works for you, that is probably the cleanest possible solution. Both systems use their preferred text file format, and neither has to fuss about it. But test carefully, this solution is full of edge cases and pitfalls. Most importantly, don't expect binary files on a text mode file system mount point to read correctly. They often will, but not necessarily always.
type inputfile | find /v "" > outputfile
That should do it. type reads input file and pipes output to find with parameters to match all lines and output them to output file. In the process, LF is converted to CRLF
A possible though quite cumbersome way is to use CertUtil.exe, an executable that is natively included since past Windows XP, if I remember correctly. Here is a possible script (let us call it conv-eol.bat; see all the explanatory rem remarks in the code):
#echo off
setlocal EnableExtensions DisableDelayedExpansion
rem // Define constants here:
set "_IFILE=%~1" & rem // (input file; first command line argument)
set "_OFILE=%~2" & rem // (output file; second command line argument)
set "_IEOL=0d" & rem // (incoming line-breaks; `0d` or `0a`)
set "_OEOL=0d 0a" & rem // (outgoing line-breaks; `0d`, `0a`, `0d 0a`, ``)
set "_TFILE1=%TEMP%\%~n0_%RANDOM%.hex" & rem // (first temporary file)
set "_TFILE2=%TEMP%\%~n0_%RANDOM%.tmp" & rem // (second temporary file)
rem // Verify input file:
< "%_IFILE%" rem/ || exit /B
rem // Convert input file to hexadecimal values (first temporary file):
CertUtil -f -encodehex "%_IFILE%" "%_TFILE1%" 4 > nul
rem // Write to second temporary file:
> "%_TFILE2%" (
setlocal EnableDelayedExpansion
rem // Read first temporary file line by line:
for /F "usebackq delims=" %%L in ("!_TFILE1!") do (
rem /* Store current line (hex. values), then replace line-breaks
rem using the given line-break codes and return result: */
set "LINE=%%L" & echo(!LINE:%_IEOL%=%_OEOL%!
)
endlocal
)
rem // Verify output file:
> "%_OFILE%" rem/ || exit /B
rem // Convert second temporary file back to text into output file:
CertUtil -f -decodehex "%_TFILE2%" "%_OFILE%" 4 > nul
rem // Clean up temporary files:
del "%_TFILE1%" "%_TFILE2%"
endlocal
exit /B
Provide the input file as the first command line argument and the output file as the second one to the script (they may even equal):
conv-eol.bat "input-file.txt" "output-file.txt"
The input and output line-breaks must be specified as hexadecimal character codes, while 0d represents the carriage-return (CR) and 0a the line-feed (LF) character.
The following table tells how to set the variables _IEOL and _OEOL at the top of the script for different line-break style conversion tasks:
from \ to||Mac (CR) ||Unix/Linux (LF) ||DOS/Windows (CR+LF)
Mac (CR) ||#####################||_IEOL=0d, _OEOL=0a ||_IEOL=0d, _OEOL=0d 0a
Unix/Linux (LF) ||_IEOL=0a, _OEOL=0d ||#####################||_IEOL=0a, _OEOL=0d 0a
DOS/Windows (CR+LF) ||_IEOL=0a, _OEOL= ||_IEOL=0d, _OEOL= ||#####################
cat file | perl -pe 's/\R/\n/g'
The following batch fragment does the trick:
del outputfile
for /f "delims=" %%x in (inputfile) do echo %%x>>outputfile
Its advantage is not relying on the find program, which is rather temperamental (hangs or doesn't work on some machines where I tested the other solutions).
In Windows XP and earlier, you can convert a text file to CRLF simply by opening and saving it in Dos Edit (or Windows Edit). Unfortunately, the Edit program was removed in Vista.
One ridiculous way. Works with the following scenarios:
Text file with a CR at end of every line.
Text file with a repeating set of CR at end of line followed by an empty line with CRLF. Good luck!
Open the file in Notepad++ (free app) and set View -> All Characters.
IF all lines end in CR then:
Open in Microsoft Wordpad - NOT - Word and save the file in MSDOS-Format.
ELSE IF lines end in CR followed by a blank line ending with CRLF then
remove the blank lines first with Notepad++. Go to Edit -> Line Operations -> Remove empty lines and save the file.
Open the file in Microsoft Wordpad and save in MSDOS-Format.
END IF
i'm trying to write an integer to a file using redirection in batch,but i can't seem to do it.All i get is empty lines.
set var_1=0
echo %var_1%>output.txt
The same happens when i try to write numbers directly without declaring a variable first.
although this is not the case when i use two digit numbers or more.
Any solution to this?
Already tried
set var_1=100
set /a var_1=0
echo %var_1%>output.txt
Didn't know why i even tried this but i did it and the problem persist.
Thank you in advance.
Update : * I've already found a solution to this after a lot of searching *
For those who are interested to the solution and explaination :
http://www.dostips.com/forum/viewtopic.php?f=3&t=4668
Problem with a digit directly before the redirector.
try
>filename echo 0
1>nul redirects standard output to nul (suppresses output)
2>nul redirects standard error to nul (suppresses error messages)
0 is standard input
3..9 similarly affected, nul can be a filename if desired.
If you try this at the console you see what is going on , you get something like
ECHO is on (aan).
Which means your 0 is neglected because the console sees it as a kind of null.
Use this instead, the space does the trick
echo %var_1% > output.txt