Pipe the output from Wmic
through more
:
wmic CPU Get AddressWidth |more >> "C:\test.txt"
Edit for some more background: the issue you see is due to wmic
output being unicode utf-16. This means that each character (or more correctly, most of them) is encoded in two bytes. wmic
also puts a so called BOM (byte order mark) at the beginning of the output. See byte content below:
FF FE 44 00 65 00 73 00-63 00 72 00 69 00 70 00 ..D.e.s.c.r.i.p.
Those first two bytes (FF FE) specify endianness for UTF-16 and allow data processing tools to recognize the encoding [being UTF-16 little endian].
Obviously type
does this check and if it finds the BOM then properly recognizes the encoding.
On the other hand, if you first echo text
and then append Wmic
output - there is no BOM at the beginning and you can see inconsistent encoding:
74 65 78 74 20 0D 0A 44-00 65 00 73 00 63 00 72 text ..D.e.s.c.r
If you put it through type
it cannot infer how to interpret, /most likely/ assumes single byte ('ANSI') and this results in spaces produced for non printable characters (zeros, being in fact high order bytes of two byte character encoding).
more
handles more (pun intended) cases and produces correct output for basic ASCII chars that's why it's commonly used as a hack for this purpose.
One additional note: some editors (notepad being simplest example) will properly display utf-16 encoded file if it is consistent - even without BOM. There is a way to force echo
to produce unicode output (but beware it does not produce BOM) - using cmd /u
causes output for internal commands to be unicode.
I can't really say why cmd unicode support is so limited (or as most would say - broken...) - probably historical/compatibility issues.
Last thing - if you need better unicode support (among many other benefits) I would recommend migrating to powershell
You have two problems. Techie007 identified the first one - You must prefix your DO command with @
if you want to prevent the command from being echoed to the screen. This is not necessary if ECHO is OFF.
The other problem is a very annoying artifact of how FOR /F interacts with the unicode output of WMIC. Somehow the unicode is improperly converted into ANSI such that each line ends with \r\r\n. FOR /F breaks at each \n, and only strips off a single terminal \r, leaving an extra unwanted \r. (Note that \r represents a carriage return character, and \n a newline character)
WMIC output includes an extra empty line at the end. The extra unwanted \r prevents FOR /F from ignoring the line (it is not seen as empty). When you ECHO the value you get ECHO is on.
There are multiple ways to handle this, but my favorite is to pass the output through an extra FOR /F to remove the unwanted \r.
for /f "skip=1 delims=" %a in ('wmic volume where "Driveletter like '%C%'" get label') do @for /f "delims=" %b in ("%a") do @echo %b
Best Answer
The output is:
LicenseStatus 1
, I want to capture the1
in a variableUse the following batch file:
Further Reading