The wmic
command is a bit different then either the VB or Powershell syntax.
The relevant syntax for wmic
is:
wmic <command> where <conditional> Assoc /assocclass:<class>
Specifically to solve the task above:
wmic DiskDrive where "DeviceID='\\\\.\\PHYSICALDRIVE<disk_index>'" Assoc /assocclass:Win32_DiskDriveToDiskPartition
Will return the partitions on the drive with the given index.
wmic partition where (DeviceID="<partition_id>") assoc /assocclass:Win32_LogicalDiskToPartition
Will return the volumes on the partition with the given id.
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
Best Answer
I don't want VariableValue to get into output. I want simply get xxx Is it possible?
Using a batch file:
Using a command line:
Notes:
for /f
loops through thewmic
output.skip=1
skips the header line (containingVariableValue
)findstr /r /v "^$"
removes the trailing blank line from thewmic
output.Example output:
Further Reading