Command tail (%$ / %*) problem

[gschizas]

There seems to be some inconsistency in the way that the two batch file parameters for command tail handle things:

Consider this batch file (cmdtail.btm):

@echo off
echo Star   -- %*
echo Dollar -- %$
echo 0 : %0
echo 1 : %1
echo 2 : %2
echo 3 : %3

When you run the following command:

cmdtail alpha beta=gamma

You get the following:

Star   -- alpha beta=gamma
Dollar -- alpha beta gamma
0 : cmdtail
1 : alpha
2 : beta
3 : gamma

Is this correct behavior? I mean the fact that %$ omits the "="? Are they supposed to be different? Did the behavior change on some version? For reference, the behavior, apart from %$ of course is the same in cmd.exe.

This is a problem that occurred from maven, so it does have real-world significance :)

Perhaps this has been posted before, but I didn't know how to search this. :)

 

[Steve Fabian]

----- Original Message -----
From: "gschizas" <>
| Is this correct behavior? I mean the fact that *%$* omits the *"="*? Are
they supposed to be different? Did the behavior change on some version? For
reference, the behavior, apart from *%$* of course is the same in cmd.exe.

Yes, several versions ago, the change was made to match a change in
CMD's misbehavior.

| This is a problem that occurred from maven (http://maven.apache.org/), so
it *does* have real-world significance :)

Yes, unfortunately this is a problem for programs that are not designed
for the latest version of CMD.EXE. And no, I am not aware of any
work-arounds, since the same problem would occur with executing the same
batch files with CMD.EXE, you must modify the files themselves.
--
Steve

 

[rconn]

> Is this correct behavior? I mean the fact that *%$* omits the *"="*?
> Are they supposed to be different? Did the behavior change on some
> version? For reference, the behavior, apart from *%$* of course is the
> same in cmd.exe.

WAD (for compatibility with CMD). I believe that %* was changed a couple of
years ago in v10 to match CMD. %$* matches the actual CMD behavior when
parsing arguments for batch files, which is to consider = as whitespace and
strip it. (As is obvious in the actual argument list your batch file
displays.)

> This is a problem that occurred from maven so it *does* have real-world significance :)

I don't understand this -- since TCC behaves identically to CMD, how does
this cause a problem with maven?

Rex Conn
JP Software

 

[gschizas]

WAD (for compatibility with CMD). I believe that %* was changed a couple of
years ago in v10 to match CMD. %$* matches the actual CMD behavior when
parsing arguments for batch files, which is to consider = as whitespace and
strip it. (As is obvious in the actual argument list your batch file
displays.)

It's all right to strip it, the only problem was that %$ (which doesn't exist on CMD) had a different behavior. %$ does strip the "=", %*, that is CMD compatible, doesn't strip it. I have to admit it makes more sense to me for TCC not to strip the "=" in any case, even though it does split the parameters in a CMD-compatible way. But I guess that could break existing batch files...

I don't understand this -- since TCC behaves identically to CMD, how does
this cause a problem with maven?

Rex Conn
JP Software

Oh, simple. Maven tried to be smart and use %* for CMD and %$ for 4NT (sic) :).

Ok, the resolution to my problem is obvious - change the mvn.bat file to NOT try and be smart and detect 4NT (especially by using if "%@eval[2+2]" == "4"). There are just two parts where mvn.bat tries to be clever (and a part that is really stupid, as it has TWO ENDLOCALs without having two SETLOCALs), I've already fixed the offending part. The other part is the fragment below, but I'm not so sure I need to change it...:

@REM -- 4NT shell
if "%@eval[2+2]" == "4" goto 4NTCWJars

@REM -- Regular WinNT shell
for %%i in ("%M2_HOME%"\boot\classworlds-*) do set CLASSWORLDS_JAR="%%i"
goto runm2

@REM The 4NT Shell from jp software
:4NTCWJars
for %%i in ("%M2_HOME%\boot\classworlds-*") do set CLASSWORLDS_JAR="%%i"
goto runm2

 

[gschizas]

| This is a problem that occurred from maven, so
it *does* have real-world significance :)

Yes, unfortunately this is a problem for programs that are not designed
for the latest version of CMD.EXE. And no, I am not aware of any
work-arounds, since the same problem would occur with executing the same
batch files with CMD.EXE, you must modify the files themselves.
--
Steve

Actually it does work with the latest (Windows 7) cmd.exe - that was the reason I found the problem. The problem was that it tried to be too smart for its own good and tried to parse 4NT (sic) in a different way than cmd.exe. There is also some code for Win9x in there as well, I guess command.com has a completely different way to parse arguments as well :)

 

[David Marcus]

WAD (for compatibility with CMD). I believe that %* was changed a couple of years ago in v10 to match CMD. %$* matches the actual CMD behavior when parsing arguments for batch files, which is to consider = as whitespace and strip it.

Is this documented in the Help? If not, I would find it useful if the facts that = is a command separator and %* and %$ differ in this regard was documented in the Help, e.g., on the "Batch File Parameters" page.