set ^"+=Why?This echo It works^^^^^^^^^^!"

[jeb]

My cat walks over my keyboard (again).

And I was supprised, that the code still works , it prints

Code: Select all

It works!

It seems that my cat knows some very strange batch tricks.

But is there anybody, who can explain how it works?

Code: Select all

@echo off
setlocal EnableDelayedExpansion
set LF=^


set ^"-=:-)^
^% ;-) %^
%  8-( %^^
%lf:^=!LF!%!LF:^
&"=<&^|>!"
set ^"+=Why?This echo It works^^^^^^^^^^!"
(%-%%+%)

jeb

[Boombox]

.
Carets ^ are for escaping other characters and are not valid here, so...

You set LF = ^Nothing

And later,

set ^"- = ^"-=:-)^^% %^% 8-( %^^%lf:^=!LF!%!LF:^&"=<&^|>!"
then again, set nothing to nothing with;

set ^"+=Why?

You can't use these characters in the name of your variables.

The only command that is valid is; echo It works^^^^^^^^^^^!"

My guess anyhow!

[foxidrive]

.
Carets ^ are for escaping other characters and are not valid here, so...

A caret also has a function as a line continuation character.

@echo off
echo abc^
def^
ghi


And the set LF technique sets LF to a Line feed character. It needs a blank line following the set LF=^

[Boombox]

.
Cool. Can we also echo to a file this way?

A caret also has a function as a line continuation character.

[foxidrive]

.
Cool. Can we also echo to a file this way?

Code: Select all

@echo off
echo abc^
def^
ghi>aaa.txt

[Ed Dyreen]

'
Is it thee the obfuscator who brings to us another of your riddles ?

My cat walks over my keyboard (again).

And I was supprised, that the code still works , it prints

Code: Select all

It works!

It seems that my cat knows some very strange batch tricks.

But is there anybody, who can explain how it works?

Code: Select all

@echo off
setlocal EnableDelayedExpansion
set LF=^


set ^"-=:-)^
^% ;-) %^
%  8-( %^^
%lf:^=!LF!%!LF:^
&"=<&^|>!"
set ^"+=Why?This echo It works^^^^^^^^^^!"
(%-%%+%)

jeb

My imagination tickled, the answer missing.

Thy must speak out loud and remove all doubt !


But let's try it on:

it looks like

Code: Select all

-=:)^


+=Why?This echo It works^^!

Then this line

Code: Select all

(%-%%+%)

expands to

Code: Select all

(:)^
Why?This echo It works^^!)

My theory: 'Why?This' as label and 'echo It works^^!)' as command on a newline.

Now there is something special about the brackets, they are not even.
The 2nd bracket becomes part of the label which evens them out.

Then there are the outer brackets, I haven't figured this one out yet

Without jokes

Code: Select all

@echo on &prompt $G

setlocal EnableDelayedExpansion
set LF=^


set ^"-=:=^^^%LF%%LF%^%LF%%LF%"

set ^"+=Why?This echo It works^^^^^^^^^^!"

(
%-%%+%
)

set ""
pause
exit

it looks like

Code: Select all

-=:=^


+=Why?This echo It works^^!

same effect.

Something similar, the self initializing label also by jeb's cat ( what do you feed that beast ?? )

Code: Select all

<   :label <nul %( null )% rem^ >nul &echo It works^^^^^^^^^^!

Would be interestingly faster if the redirections could be eliminated

Code: Select all

@echo on &prompt $G

setlocal EnableDelayedExpansion
set LF=^


:label^%LF%%LF% echo.this doesn't work.

pause
exit

But this doesn't work, and the label can only be found if it is not in a variable, as far as I know.

ed

[jeb]

The candidate got 90 points of 100.

Is it thee the obfuscator who brings to us another of your riddles ?

Ok, it was obfuscated , but I suppose that the main trick is currently unknown

My theory: 'Why?This' as label AND 'echo It works^^!)' as command on a newline

Good theory, but wrong

Something similar, the self initializing label also by jeb's cat ( what do you feed that beast ?? )

No, this is interessting too, but a complete other technic.

Would be interestingly faster if the redirections could be eliminated

Code: Select all

@echo on &prompt $G

setlocal EnableDelayedExpansion
set LF=^


:label^%LF%%LF% echo.this doesn't work.

pause
exit

But this doesn't work, and the label can only be found if it is not in a variable, as far as I know.

Yes, it can only be found if it's not in a variable.
But your code fails also, as linefeeds works only inside of brackets this way.

Code: Select all

set LF=^


(
:label%LF% echo.this work.
)

But you are on a good way to simplify the problem and bring it to the simplest form.

jeb

[Ed Dyreen]

Yes, it can only be found if it's not in a variable.
But your code fails also, as linefeeds works only inside of brackets this way.

Code: Select all

set LF=^


(
:label%LF% echo.this work.
)

Aha, that's new to me and explains why they are required.

I remember another of your posts where you explain how some characters '+', ')', '=' can break things.
No time to digg that post right now, maybe some other time...

But you are on a good way to simplify the problem and bring it to the simplest form.

Hmm, thee who knows the answers should not hold em back, this why everybody hates you

[jeb]

Ok, I will try to explain the main thing.

Code: Select all

(
echo 1
:label1 NoSpace^

This line is invisible
echo Secondary line

echo 2
:label2 space ^
This line is invisible
echo Secondary line

echo 3
:label3 space ^

The_first_token_wil_be_removed ECHO This works

echo 4
^

blaBla echo this works too

set "x=x" ^

this doesn't work
)

The label3 sample works.
It removes the first token from the next line, as you can see it depends on two things.
It needs an empty line and a space (or any delimiter ";,=)&|<>" ) just before the multiline caret.

But it does not depends on labels, like the fourth sample demonstrates.

What is the underlying rule
Why it works this way

I have no really good ideas. Only one very weak assumption.

As it depends on a character in front of the caret and it needs an embedded linefeed,
I suppose the parser write the characters into a command buffer, but in this case the order of the characters is wrong.
So the linefeed can start a new line but at the wrong place (ok I said it's only a weak guess).

jeb

[Aacini]

May I suggest to kill jeb's cat?

Antonio

[dbenham]

I was wondering how many lives were left for that damn cat

But that is very interesting newly discovered behavior in cases 3 and 4. There is one more requirement that you did not mention: cases 3 and 4 must be enclosed within parentheses. Without the parentheses they give the same result as case 1.

Cases 1 and 2, and the SET case tacked on at the end, all make sense based on previously known CMD parsing features. They continue to work even if they are not enclosed within parentheses.

It seems like there ought to be a clever use for this newly discovered insane behavior, but I haven't come up with one as of yet. At first I thought it might help with a hybrid batch/VBScript solution with no funny characters and no extraneous output. But I couldn't figure out how to hide the opening parenthesis from VBS.


Dave Benham

[jeb]

Hi Dave,

At first I thought it might help with a hybrid batch/VBScript solution with no funny characters and no extraneous output. But I couldn't figure out how to hide the opening parenthesis from VBS.

That's a quite good idea
You don't need to hide the opening parenthesis from VBS, for this case I have a solution.

Code: Select all

:'The next line is onyl visible for VBS^
echo="echo"

:'The next line is onyl visible for VBS^
hello="hello"

:'The next line is onyl visible for VBS^
dummy="x"+_
(echo+hello)

In vbs the code is valid and prints nothing.
As batch it's prints "hello".

But currently I don't know how to place a lable inside the parenthesis to use the new effect.

jeb