DosTips.com

CMD BUG

This won't work !
This works !

That is odd - It doesn't look like expected behavior to me.

It works as expected on my Vista machine.


Dave Benham

'
Yes, odd but it's real, tested in both VM and physicall pc running XP 32...

It only seems to affect echo commands.
At first I thought echo_ was interpreted as echo. and that that was the reason it failed,
but then i tested with 2necho_ and @2necho_ which led me too conclude this is another weird XP bug.

You edited your post while I was preparing my 1st post.

To clarify - I do not see the behavior below on Vista
I get the expected This

This works for me on the command line in Vista, but fails in batch


Dave Benham

'
So it's not just an XP bug,

try this one, it's even weirder, same result:

False alarm.

I forgot SET /P does not print newline.

So %@21echo_%This is giving correct result in Vista in batch and on command line.

I fooled myself as far as changing behavior - I had modified the code slightly.

Whew!

'
WhoeHaa The .DOT is affected as well

I could have guessed it, AND the DELIMS , as well...

I don't understand - show some examples please.

I am guessing that English is not the native language for

echo_This wordt niet herkend als een interne
of externe opdracht, programma of batchbestand.

Is it possible that Windows might alter its behaviour when installed for a foreign (to me) language ?

You should avoid leading numbers in variable names. The reason why is simple:
%2echo_%
Is %2 an argument or is it part of a variable?

You could try the same with delayed expansion. Then you (and also cmd) are not that confused.
!2echo_!

Regards
aGerman

'

aGerman wrote:You should avoid leading numbers in variable names. The reason why is simple:
%2echo_%
Is %2 an argument or is it part of a variable?

Your conclusion is not correct, it doesn't explain, next behavior on XP:
As you can see it's the combination of both a leading digit and an ending "special" character that is causing it ! DOS tells me, it can't decide whether it is part of a variable because of the underscore at the end.
Remove the ending underscore, and DOS will accept it as a variable so

%2echo_% -> %2 is it a variable ???
%2echo% -> %2 it is a variable.

Tested these to be sure DOS does not interpret %2echo_% as %2 and echo_

%2@echo_% -> %2 is it a variable ???
%2@echo% -> %2 it is a variable.
%2YOecho_% -> %2 is it a variable ???
%2YOecho% -> %2 it is a variable.

Do we have a bug, or can it still be explained

Well Ed, the cmd on XP has a different behaviour. We all know that. But the main reason why it fails is the ambiguous %2. Perhaps it's an XP bug. However, M$ changed the bahaviour and now a variable with a leading number seems to be always parsed as an argument + string.
Because I never tested that much on XP I never used a combination with leading numbers. It's obvious that it would probably fail, isn't it.

Regards
aGerman

@aGerman - thank you - your explanation makes perfect sense.

Ed Dyreen wrote:'

aGerman wrote:You should avoid leading numbers in variable names. The reason why is simple:
%2echo_%
Is %2 an argument or is it part of a variable?

Your conclusion is not correct, it doesn't explain, next behavior on XP:

Code: Select all

@echo off

set "2echo_=>&2 <nul set /p ="
%2echo_% Hello
pause

set "2echo=>&2 <nul set /p ="
%2echo% Hello
pause

As you can see it's the combination of both a leading digit and an ending "special" character that is causing it !

Code: Select all

echo_ wordt niet herkend als een interne
of externe opdracht, programma of batchbestand.
Druk op een toets om door te gaan. . .
Hello
Druk op een toets om door te gaan. . .

DOS tells me, it can't decide whether it is part of a variable because of the underscore at the end.
Remove the ending underscore, and DOS will accept it as a variable...

Ed - I'm not getting the same results as you.
All macro variants that begin with a number fail for me on both Vista and XP within a batch, even if there is no underscore on the end. All variants that do not begin with a number succeed. This is the behavior I expect with aGerman's explanation.

If I run the macros from the command line, then all variants work, again backing up aGerman's explanation since the command line does not attempt batch argument expansion.

The failures you are getting only occur in batch, correct
You can run your batch with 2 arguments passed in and you should see the 2nd argument as part of your error message for the %2echo_% case.

The big mystery is why the %2echo% variant works in batch mode for you. You did test it in batch mode, yes

Have you loaded and/or executed any of your macros prior to testing
I'm thinking of the macros that exhibit the nasty XP FOR /F bug. I know that you are suppressing and/or ignoring the FOR /F error messages. I'm worried that if you run such macros and then run your ECHO macro tests, your machine might be in an unstable state. Try running the ECHO macro test with minimal code in a virgin CMD window.


Dave Benham

'
Dave, that is exactly what I tried.

I am running Service Pack 2 here, the VM runs service pack 1, both give me same results.
maybe it's service pack related.

If so, that would become a problem when my unattended scripts attempts updating to SP3

All the tests were done using a "blank" batch file, I did not call it, just a mouseclick ...

I will try different systems,... ...