This may well be an xp.sp3 quirk, haven't tried it elsewhere, yet. But it's quite odd. Here's the code...

Save it as, say, recurse.cmd, and run it with an argument of 2. Output comes out as expected, copied below.

Now, replace the "call :exec %%0 rearg1" line towards the top with "call :exec-fail %%0 rearg1" and run again...

I cannot explain the execution flow between these two lines.

The only difference between :exec (which works) and :exec-fail (which goes wild) is that the former makes a temporary variable !exec! which it then executes, while the latter attempts to run the same command line directly.

Liviu

Both exec and exec-fail are "broken"

You are invoking a batch from within another batch without a CALL statement. Forget for the moment that the batch is executing itself. Control is supposed to be transferred to the 2nd batch and it is not supposed to return to the original batch. BUT, you are invoking the 2nd batch after having made a CALL within the 1st, so it HAS to return. I don't think the language has a defined behavior for that.

I am getting slightly different behavior on Vista 64 then what you report on XP. But it is still equally as weird.

To make things easier to understand, I've simplified the situation by replacing the recursive nature with 2 batch files - part1 and part2.

part1.bat

part2.bat

results after executing part1:

In all cases, none of the part1 subroutines finish - they are truncated once part 2 is called. In all cases, the part1 subroutines do return to the main part1 program.

The interesting bit is what happens when part2 is invoked.

When part2 is invoked directly from within the part1 :direct routine, control is immediately transferred to the :direct label in part2 - the top of the script is ignored

When part2 is invoked directly from within the part1 :direct2 routine, part2 fails entirely because it is looking for a :direct2 label and fails to find it

When part2 is invoked indirectly via delayed expansion from within part1 :indirect, it executes normally from the top. The :indirect label is ignored.

The extra output concerning var=value and arg1 is just to prove that the SETLOCAL is being terminated properly when the subroutines return, and also that the arguments are passed to part2 properly.

I find this very interesting. I wonder if jeb has seen this before, or if there is a use for this weird behavior.

Dave Benham

For different values of "broken", though

Your example verifies that the :indirect call (my :exec) does indeed work in the sense that I meant in the original post - execute an external program without an explicit "call" or "cmd /c" which cause a reparse of the command line.

Now, your :direct call (my :exec-fail) probably explains the execution flow oddity that I noted, yet it's not entirely clear to me how the parameters got shifted there. But you're right, the recursion likely added another layer of complexity on top of what's a very strange behavior already.

That said, this :direct behavior (if verified/confirmed/portable/etc) could be a very useful trick on its own. It basically amounts to being able to call individual labels inside an external batch file. Haven't measured and won't comment on performance, but such a feature could come in quite handy for "library" purposes. For example, it would allow code like...

Liviu

I love new behaviour

I tested it with Win7 x64 and it "works" (implicit jump is active)

The implicit jump is strange

But I can't imagine how bad the code must be in cmd.exe that this can occour.
Even the strangest anti-pattern shouldn't produce this

Btw. I suppose this is a goto not a call, as in %0 is the name of the batch file, not the name of the function

part1.bat


part2.bat


jeb

I was wondering the same... My imagination cannot fathom a scenario where this could be the side effect of even the weirdest implementation bug. Alternative theory might then be that it's a "hidden feature" for whatever purposes e.g. to somehow aid in-house batch file debugging. However, I find that theory unsatisfactory, too. So, bottom line, I am just as mystified as you are.

Liviu

Right. However, it seems to be very "syntactically sensitive". If, in part1, you replace the "part2 argFromPart1" line with "if 0==0 part2 argFromPart1" then the part2 execution will start at the top, instead. And, in all cases, replacing "exit /b" with just "exit" will close the original part1 console itself.

Liviu

Stop finding these ridiculous cases - my brain hurts

It seems that the implicit jump fails to "work" if there is anything other than command line token delimiters before part2. (ie <space> <tab> ; , = )

All of the following start at the top

Even this starts at the top


Nothing unusual there. That is how EXIT always works, hence the need for the /B option.


Dave Benham

I totally absolutely disagree - it could be a deliberate assist for in-house purposes.

Some years ago it was either an Emergency Out of Band or a Patch Tuesday Security update that "updated" the heart of Windows.
I am fairly certain it was Explorer.exe.
Strange thing is that the new versions was :-
Significantly smaller ;
had identical version strings and creation / modification dates.

When I developed software using the 'C' language, a simple Header.H file determined whether DEBUG=TRUE or DEBUG=FALSE.
During development the DEBUG code was active and wasted 90% of the CPU cycles to ensure that only 10% was needed by active code,
and there were many supplementary run-time checks to facilitate testing and validate all assumptions,
and a flag on display to ensure instant recognition if DEBUG code ever got into equipment for the customer.

I never failed to cancel DEBUG=TRUE when releasing code to production.

It was instantly recognizable to me that regardless of whether Microsoft use 'C' or something else,
they had issued Explorer.exe with some form of "DEBUG" incorporated,
and the latest exploit was utilizing their "DEBUG" code,
hence Security update merely cancelled the "DEBUG" mode and thus stripped out the malware target and gave a SMALLER executable,
but the software library was totally unaltered - no other files were changed, no version strings were updated.

CMD.EXE starts with what COMMAND.COM did, does not quite implement exactly what it did, and throws in a great big bundle of extras.
It obviously needed debugging and I doubt that I am the only genius to use a tiny change in one file to supplement the intended product with extra DEBUG goodies.

30 years ago my software ran 24 hours a day 365 days a year giving non-stop security protection to military installations.
I never risked releasing DEBUG code

DOS and Windows were happy to give BSOD's every day and swear at users for not "shutting down properly.
The probably bundle DEBUG into everything they do and simply flip the debug switch when malware targets that aspect of Windows.

Right, of course. Yet "always" is relative to the charted territories. The behavior in this case was odd enough that I honestly didn't know what to expect, even from trusted straightforward commands like EXIT


I tend to agree more now, after the latest findings that even slight/cosmetic syntax changes cause the behavior to revert to the expected default. This could indeed be a sign of some deliberate "easter egg", be it intended for debugging or other purposes. That helps support with calls like: "oh, you stumbled upon our little secret feature we thought no sane user would find, but just throw a pair of paranthesis around the line, and it will work again as advertised".

Liviu