TYPE is used mostly to view small ASCII files, like AUTOEXEC.BAT.
But it can als be used to:
TYPE has at least one feature that makes it well suited to perform other tasks than plain text file viewing: it doesn't lock the file it views.
This makes it an excellent program to view and even copy log files that are locked by another program.
The viewing will be obvious, here, but how about copying? Take a look at the example:
TYPE logfile.log > logfile.bak
Without the redirection to logfile.bak this would show the contents of logfile.log on screen.
Because of the redirection, though, these contents will now be stored in logfile.bak.
That way, the content of logfile.bak will be identical to logfile.log's, though it will have a different timestamp.
This may be useful if you need to copy a text file that may be in use, when
COPY may fail.
This example demonstrates the combined use of TYPE and FIND to remove a line from an ASCII file (warning: real DOS only):
TYPE C:\CONFIG.SYS | FIND /V /I "SHARE.EXE" > C:\CONFIG.SYS
Since we use piping of TYPE's standard output to FIND's standard input, the content of CONFIG.SYS is stored in one or more temporary files before FIND's standard output will overwrite CONFIG.SYS again.
Without piping to FIND's standard input, CONFIG.SYS would be opened by TYPE and at the same time be overwritten by TYPE's standard output.
This would result in either an error message (if you're lucky) or an empty CONFIG.SYS.
|Warning:||This trick won't allways work in multi-tasking environments like Windows NT or OS/2! You may find that you end up with an empty file using this trick.
Use different source and target file names to be on the safe side.
I often use TYPE to check a download's progress:
If you use DIR to display file sizes, files being downloaded seem to have a file size of 0 bytes.
By using TYPE once to display the contents of the file, next time DIR will show the actual amount of bytes already downloaded.
This won't hurt the download, since TYPE does in no way lock the file.
Use TYPE and DIR again to check on download progress:
DIR download_in_progress TYPE download_in_progress > NUL DIR download_in_progress
download_in_progress is the name of the file being downloaded.
In Windows 2000 and later, TYPE offers a simple method to convert Unicode files to ASCII:
TYPE MyUnicode.txt > MyASCII.txt
Or, if "extended" ASCII characters like
à may be involved:
CHCP 1252 TYPE unicode.txt > ascii.txt
1252 is the most commonly used codepage for western languages in Windows 2000 and later.
Use a different code page for other languages.
Until recently, I believed conversion from ASCII to Unicode to be more complicated.
But then Jacques Bensimon showed me a really simple way:
CMD /U /C TYPE ascii.txt > unicode.txt
A note from Jacques Bensimon:
I thought I'd point out that, although the technique I mentioned does correctly convert ANSI characters to Unicode, the resulting file (which is exactly twice the size of the original) does not comply perfectly with what appears to be the standard for a Unicode text file (at least as far as Windows is concerned): a file saved as Unicode by Windows (e.g. Notepad) has the 2-byte header
0xFF 0xFEas its first two characters and I've noticed that some programs that expect a Unicode file (for example a custom dictionary file in Office 2007) will not accept a "bare" Unicode file without that header.
An easy way to take care of this (when necessary) is to first create and keep somewhere an empty Unicode text file (let's call it UniHeader.txt) consisting only of the two bytes in question (just create an empty text file and save it as Unicode using Notepad to achieve this).
From then on, when you want to convert an ANSI text file to a "true" Unicode text file, you can use the following two commands:
COPY /Y UniHeader.txt Unicode_Output.txt
CMD /U /C Type ANSI_Input.txt >> Unicode_Output.txt
Just a variation on the original theme, but this creates an output file the size of which is twice the original size + 2.
Personally, I prefer a "self-contained" batch file that doesn't need a helper file, so I slightly modified Jacques' idea:
> Unicode_Output.txt ECHO.▌■ CMD /U /C Type ANSI_Input.txt >> Unicode_Output.txt
▌■ at the end of the first command line: these represent the 2 characters Jacques mentioned.
They are not the actual characters, as these cannot be displayed on a web page: see Note 2!
Not every editor will allow the insertion of the 2 required characters, but any dedicated programming/scripting editor will.
Too bad this solution adds an extra carriage return/linefeed.
Jacques came with a solution once again:
If a non-native Windows utility is allowed, echo.exe (a port of the Unix version of echo) can echo arbitrary characters (specified as octal values) and can optionally not output any trailing newline characters (-n switch), so you can use:
echo.exe -n \377\376> Unicode_Output.txt
The ".exe" is necessary (unless you rename the utility) to avoid conflict with the internal
You can use the parameter "-- help" to see the full echo.exe syntax.
Or, if you still have a copy of BATCHMAN available somewhere, you may want to try its
CECHO C command:
BATCHMAN CECHO C 07, ▌■> Unicode_Output.txt CMD /U /C Type ANSI_Input.txt >> Unicode_Output.txt
Or use the "almost native" CHOICE command (alternative solution, also by Jacques Bensimon):
CHOICE /N /M ▌■ < NUL 2> NUL > Unicode_Output.txt
Keep in mind, though, that CHOICE will insert an extra space.
|Update:||Carlos M. solved the Unicode header problem brilliantly:
View and download his A2U.bat for more details.
|Notes:||(1)||To save and restore the original codepage, use this command before changing the codepage:
or in case your Windows version appends a dot at the end of
and then use the following command to restore the original codepage afterwards:
|(2)||Even though TYPE has been successfuly used to convert to ASCII or Unicode on many computers, it has been reported to fail occasionaly.
This may be caused by copying the batch code from this web page, instead of downloading the ZIP files containing the code.
There is NO WAY to correctly display the ASCII characters 0xFF and 0xFE, required for the Byte Order Mark, on a web page.
So it is useless to copy and paste the code from this web page, unless you manually adjust the 2 characters in the pasted code.
Better download the code; that does work flawlessly.
|(3)||In case you are one of those "lucky" few who still cannot get this working, download and use ASCII2Uc.vbs (or ASCII2Uc.bat) and Txt2ASCI.vbs instead:
In Windows NT and later, TYPE combined with MORE offers a convenient way to convert solitary linefeeds (i.e. Unix text files) to carriage return/linefeed pairs:
TYPE input_filename | MORE /E /P > output_filename