5

I have some trouble with cmd.exe. I use it sometimes to create files and write there the output. But if I try this:

wmic logicaldisk get name, freespace >> output.txt
echo %date% >> output.txt

And I start it two to three times, I get an output.txt like:

FreeSpace    Name  
17990881280  C:    
             D:    
㠱〮⸴〲㈱ഠ䘊爀攀攀匀瀀愀挀攀    一愀洀攀  ഀ਀㄀㜀㤀㤀　㠀㠀㄀㈀㠀　  䌀㨀    ഀ਀             䐀㨀    ഀ਀㄀⸸㐰㈮㄰′਍

Well, the Chinese text there looks funny, but I would like to see the date. I think somehow the encoding is changed with date. Everything is fine and I get the date if I do echo %date% >> output.txt alone.

I would like to get the wmic output and the date.

What should I do?

Mofi
  • 46,139
  • 17
  • 80
  • 143
sabisabi
  • 1,501
  • 5
  • 22
  • 40

3 Answers3

8

The reason is that WMIC outputs to UNICODE. While the batch commands outputs to ANSI by default. Since the ANSI codepage is smaller than UNICODE and mapped differently, converting between them becomes a problem. There are several ways to solve this problem.

A. Start the command shell with the /U switch or if already in a command prompt, just type cmd /U.

Help from the "Help cmd" command: /U Causes the output of internal commands to a pipe or file to be Unicode

Thus, you will end up with a UNICODE text file and your original code needs no modification. However, you will need to remember to always use the /U switch. Also the correct way to do it is :

    wmic /OUTPUT:output.txt logicaldisk get name, freespace
    echo %date% >> output.txt

B. Convert the WMIC output to ANSI (Recommended. However depends on what you need. Just makes life easier when you decide to add to the text file. However, you will have to use 2 output files.).

   wmic /OUTPUT:output.tmp logicaldisk get name, freespace
   TYPE output.tmp > output.txt
   echo %date% >> output.txt

Hope this will help someone.

Dharma Leonardi
  • 101
  • 2
  • 3
7

WMIC has some weird output. I've seen a discussion where it was said WMIC uses unicode, but I think the situation is more complicated than that. If I capture WMIC output to a file and use a hex editor, I see an extra carriage return at the end of each line. I am completely at a loss as to how the date content is converted into gibberish when the output.txt is typed. (codepage issue? but how?) On my machine I get question marks where the date should be.

I was able to fix the problem by using

wmic logicaldisk get name, freespace | more >>output.txt
echo %date%>>output.txt
dbenham
  • 127,446
  • 28
  • 251
  • 390
  • thanks it works. I wish I would understand why. Is the encoding changed with `| more` ? – sabisabi Apr 18 '12 at 14:51
  • @sabisabi - I also wish I understood what is going on. I don't understand the root problem enough to postulate how the fix works. – dbenham Apr 18 '12 at 15:39
  • Ok ^^ the most important thing is that it works. If somebody knows why the answer can be posted as comment :) – sabisabi Apr 19 '12 at 10:57
  • @sabisabi - I have confirmed that WMIC produces unicode output, and `| MORE` does change the encoding, sort of... The pipe converts to ANSI except it introduces an extra carriage return at the end of each line. There is some bizarre behavior going on that I am still investigating. – dbenham Apr 19 '12 at 11:13
  • 2
    @sabisabi - MORE by itself can convert unicode to ansi accurately, but WMIC seems to have some flawed conversion built in whenever its output is piped. So the WMIC output is already "converted" before MORE gets a hold of it. Normal WMIC output is healthy unicode. Piped output is converted to ansi, except there is an extra carriage return at the end of each line, and there is an extra new line (with extra carriage return) at the end of the output. Based on a number of experiments, WMIC seems to do this itself, but only when the output is piped. Pipes not involving WMIC do not alter the output. – dbenham Apr 19 '12 at 22:45
  • 1
    My last statement was not quite corrrect - pipes will append `` to the end of the input if the last byte is not a ``. Other than that, they do not alter the output. – dbenham Apr 20 '12 at 01:12
1

I found that a batch script used to create a txt output file using stdout ">>" to create the txt file is compatible with powershell's output format ascii, utf8 and utf7, all other output formats result in extra spaces seen in the file.

If the output file is created with powershells stdout ">>" then any stdout additions to the file from a batch script will appear as Chinese characters.

The workaround in my case was to re-create the output file with the batch script and it will be in the correct format and subsequent powershell additions must use "| out-file -encoding ascii/utf8/utf7"

Will
  • 131
  • 1
  • 1
  • 9