WMIC and FOR /F : A fix for the trailing <CR> problem

[dbenham]

Under Win XP the \r characters were all ignored/removed when using with "for/F (string)":

40 65 63 68 6F 20 6F 66 66 0D 0A 66 6F 72 20 2F 46 20 22 64 65 6C 69 6D 73 3D 22 20 25 25 61 20 69 6E 20 28 22 0D 30 0D 31 0D 32 0D 33 0D 22 29 20 64 6F 20 65 63 68 6F 20 40 25 25 61 80 0D 0A

@echo off
setlocal enableDelayedExpansion
for /F "delims=" %%a in ("\r0\r1\r2\r3\r") do echo @%%a€

Code: Select all

Z:\>test
@0123Ç

No, you got fooled

The \r characters were stripped in phase 1.5 of the normal batch parser. In your script it has nothing to do with FOR /F.

Even on XP, FOR /F does not strip all \r from input - it only strips the very last character (before \n) if it happens to be \r. All other \r are preserved. The safe return technique would not work if this were not the case.

You can prove this by having FOR /F read a file containing a line that looks like "\r0\r1\r2\r3\r\r\n". Another option is to get that string into a variable, and then use FOR /F with IN("!var!").


Dave Benham

[siberia-man]

Code: Select all

for /f "tokens=*" %a in ( 'wmic os get localDateTime /value' ) do @call echo [%a]

And much better

Code: Select all

for /f "tokens=*" %a in ( 'wmic os get localDateTime /value ^| findstr "."' ) do @call echo [%a]

[penpen]

@dbenham
Yes, you're right: I've tricked myself. (Edited my above post.)

@penpen
(...)But I don't understand why the WMIC should change the encoding.
Although I know that there are WMIC versions that don't output in unicode.

To figure out the programmers intentions is not easy... . There could me various reasons, so i just guess:
Maybe they don't wanted the "System.Text.SBCSCodePageEncoding" (C#: Console.Out.Write ("{0}", Console.Out.Encoding);) to alter the string so the user always is able to see(/store in batch variable) things like the real process names, ... .
(User friendly in this case.)

Onother option is that Microsoft just wanted to ensure that the output is unicode in the unicode version - up to now i didn't even know, that there are unicode and ansi versions.
(Default programmers behaviour: Don't trust in(/ou)tput (devices) => ensure the predicted behaviour: Unicode output in this case.).

It also may be that Microsoft plans to change the default bahaviour of the cmd streams, or want to get rid of multiple implementations of the same functions caused by using ansi AND unicode.
(Similar to Java's "deprecation".)

(...)

penpen

[aGerman]

It also may be that Microsoft plans to change the default bahaviour of the cmd streams, or want to get rid of multiple implementations of the same functions caused by using ansi AND unicode.

I think they already force us to use PowerShell. I've heard the CMD is already missing under the newest Windows server versions.

Regards
aGerman

[Liviu]

I've heard the CMD is already missing under the newest Windows server versions.

CMD is alive and well up to the latest Server 2012 R2 (the server edition of 8.1 - http://technet.microsoft.com/library/hh831786.aspx). Actually, Server versions have had the "Core" option for a while now, which basically installs no GUI and boots to the CMD prompt (with PowerShell available from there).

Liviu

[aGerman]

Hmm, I must have confused something then. I was pretty sure I read something about it. Maybe I'll find the link somewhere. Nevertheless it's good to know they finally continue the support of Batch.

Regards
aGerman

[Liviu]

Maybe it was from an unhappy student who couldn't find the CMD prompt on the school or library computer It _is_ possible to disable the prompt (and batch execution altogether) via "group policies" on both workstation and server versions of Windows, but that's not the default and it's not new - has been there since Win2K at least.

Liviu