Strange bug when CMD /? is redirected to CON

[Aacini]

The CMD /? or HELP CMD commands show the help on cmd.exe usage in the screen; this works correctly even if the output is redirected to a disk file. However, if the output is redirected to CON, a strange bug happen:

Code: Select all

C:\Users\Antonio\Documents\Tests> ver

Microsoft Windows [Versión 6.2.9200]

C:\Users\Antonio\Documents\Tests> cmd /? > CON
s, conservando el
        texto que venga después de ésta.

n
?.
ión.
.


C:\Users\Antonio\Documents\Tests> help cmd > CON
s, conservando el
        texto que venga después de ésta.

n
?.
ión.
.


C:\Users\Antonio\Documents\Tests> 

The text appear in the screen in just one line with strange characters, but it seems that some characters are LF's because the line was expanded when I pasted it.

The purpose of this redirection is show the cmd.exe help without pauses. When IF /?, FOR /?, SET /? or CMD /? commands are executed, the output pauses at each page and there is no way to avoid this point. I discovered that redirecting the output to CON show the help on the screen with no pauses, but this fail in the case of CMD /? Windows 8.1 Spanish here...

Antonio

[Squashman]

Windows 10 English.

Code: Select all

C:\Users\Squashman>cmd /? >con
       any text after the last quote character.

sor\AutoRun
 specifics.

[dbenham]

This behavior does not surprise me too much - I have seen other odd behaviors when redirecting stdout to con. For example, the CLS command does not work properly. This "feature" can be useful for capturing a FormFeed (0x0c) character in a variable.

Code: Select all

@echo off
setlocal
set "FF="
>con (for /f %%A in ('cls') do set "FF=%%A")
set FF

I find it interesting that redirection within the IN clause prints the FF character to the screen, and is not captured by FOR /F

Code: Select all

@echo off
setlocal
set "FF="
for /f %%A in ('cls ^>con') do set "FF=%%A"
echo(
set FF

Dave Benham

[elzooilogico]

Antonio not sure if your actual question is only about this odd behaviour, or

The purpose of this redirection is show the cmd.exe help without pauses.

This works for me (win 8 Spanish)

Code: Select all

cmd /? | find /V ""

[penpen]

but this fail in the case of CMD /?

CON and STDOUT are different (file) devices/streams.

STDOUT is the default output stream offered by the command line processor:
It applies text formatting and sends the result to CON.

CON is the default output stream offered by the command window:
No text formatting is applied (except at the line end possibly removing the start of a string).

Why does something like ">con if /?" work properly, while ">con cmd /?" doesn't?
Because the first uses the same process/thread instance (with no redirected stdout) while the second creates a new one.

You could use help.exe to see the same for if:

Code: Select all

>con help if

(You create an subprocess with redirected stdout; also works with help command itself.)

This "feature" can be useful for capturing a FormFeed (0x0c) character in a variable.

It should also work without ">con":

Code: Select all

@echo off
setlocal
set "FF="
for /f %%A in ('cls') do set "FF=%%A"
set FF

I find it interesting that redirection within the IN clause prints the FF character to the screen, and is not captured by FOR /F

Only stdout of the command within for is captured by for:

Code: Select all

@echo off
setlocal
set "FF="
for /f %%A in ('cls ^>^&2') do set "FF=%%A"
set FF
for /f %%A in ('cls ^>nul') do set "FF=%%A"
set FF
for /f %%A in ('cls ^>file.txt') do set "FF=%%A"
set FF

penpen

[dbenham]

Thanks for the explanation penpen

Why does something like ">con if /?" work properly, while ">con cmd /?" doesn't?
Because the first uses the same process/thread instance (with no redirected stdout) while the second creates a new one.

You could use help.exe to see the same for if:

Code: Select all

>con help if

(You create an subprocess with redirected stdout; also works with help command itself.)

You can see the output of any command without text formatting by using >CON CMD /C

Code: Select all

>con cmd /c if /?
>con cmd /c type test.txt
>con cmd /c findstr "^" test.txt

This "feature" can be useful for capturing a FormFeed (0x0c) character in a variable.

It should also work without ">con":

Code: Select all

@echo off
setlocal
set "FF="
for /f %%A in ('cls') do set "FF=%%A"
set FF

I had noticed that >CON CLS prints the funny character instead of clearing the screen, and I fooled myself as to what it took to capture the character. Thanks for setting me straight - it makes perfect sense now.


Dave Benham

[Aacini]

Antonio not sure if your actual question is only about this odd behaviour, or

The purpose of this redirection is show the cmd.exe help without pauses.

This works for me (win 8 Spanish)

Code: Select all

cmd /? | find /V ""

Thank you for this suggestion; this solves my problem in the simplest way...

Antonio

[NunoLava1998]

When i try this is the result i get:

Code: Select all

Starts a new instance of the Windows command interpreter

CMD [/A | /U] [/Q] [/D] [/E:ON | /E:OFF]racter.


cs.

The only problem is it has a bunch of umm..'s and in the command line it acts like a single line.