forEntireLine, path, memory, call &weird behavior problem.

[Ed Dyreen]

'
There is nothing wrong with this command right ?
place it on top of your batch and you'll see it works perfectly.

Code: Select all

echo.path=%path%_
for /f ^"usebackq^ eol^=^

^ delims^=^" %%! in ( '"path WIN32_PRODUCT get Caption", 0, $Products' ) do echo.ok

we leave path untouched ofcourse.

Now let's assign some variables, lets make sure CMD uses at least 10.000kb of memory.
Let's call very deep into our functions lets say 3 levels deep.

Now the weird part, this is what cmd tells me after yet another call which brings us 4 levels deep.

Now I execute the above command again, and guess what DOS tells me:
popupWindow: 'CMD.EXE'

Code: Select all

Please insert disk into drive A:

RETRY,IGNORE,CANCEL

Then I change 'path WIN32_PRODUCT' -> '#path WIN32_PRODUCT'
And ofcourse the command works again.

But why ?

I've been figuring this one out for 4 hours now, did I forgot an endlocal somewhere ? did I used goto :eof where I shouldn't have, is the memory full ? Is there some kind of maximum allocatable memory in DOS (my script sometimes uses up to an amazing 17MB of memory) ?

Can't figure it out

PS: some claim: "%%~a.^!%%~a^!" will work in macros, well on XP it gives the file attributes:
name.------a--
in macros it only works without the tilde "%%~a.^!%%a^!" gives:
name.value
This means %%a can never be quoted !
What is really strange is that on XP starting from %%b the tilde variant suddenly works again
This is why in the past, I always started a for with %%b as first token.

[jeb]

Hi Mr. Ed-too-complex,

do you can build a SMALL sample to produce this?
It could be a memory overflow, as cmd.exe have some of them, I can remember that aGerman found one with extreme nesting of IF-blocks.

Jeb

[Ed Dyreen]

'

do you can build a SMALL sample to produce this?

That's a problem, I'm not sure what is happening and why it's happening.

I know that after the library is loaded CMD.EXE uses 10MB of memory.
I know that the situation is like call func -> calls func -> calls func -> calls func.
I know %path% is untouched.
I know typing path in the terminal produces the same output as echo.%path%
I know that CMD may fail to start "" "program.exe" when many variables are assigned !

I am guessing it's something with for /f and useback and '"path WIN_32.."'
I am guessing for /f tries to evaluate the %path%

When I precede the path with a symbol #path, for behaves normally again.

This solves my problem even if I don't understand it, because lucky me, my parser strips the # symbol.
I think it's a bug, I just keep wondering whether there is a limit in memory for assigning variables.
There must be a memory limit as I find it hard to believe you could just assign variables endlessly.
It's really important for me to know that limit, as beyond it DOS will probably start to fail.

I will build an endless loop assigning variables endlessly. Let's see how long I can keep doing that.
I am busy for the moment, in a few days I'll do some more testing