# 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):

Code:
``````@echo off
echo Star   -- %*
echo Dollar -- %\$
echo 0 : %0
echo 1 : %1
echo 2 : %2
echo 3 : %3``````
When you run the following command:

Code:
``cmdtail alpha beta=gamma``
You get the following:

Code:
``````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...:

Code:
``````@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.

Replies
8
Views
277
Replies
1
Views
170
Replies
15
Views
306
Replies
11
Views
552
Replies
10
Views
293
Replies
6
Views
289
Replies
5
Views
380
Replies
2
Views
158
Replies
1
Views
204
Replies
0
Views
170
Replies
11
Views
511
Replies
3
Views
299
Replies
33
Views
738
Replies
9
Views
344
Replies
3
Views
230
Replies
1
Views
228
Replies
14
Views
444
Replies
0
Views
313
Replies
1
Views
293
Replies
5
Views
327
Replies
0
Views
272
Replies
3
Views
444
Replies
5
Views
262
Replies
14
Views
414
Replies
8
Views
336
Replies
6
Views
302
Replies
0
Views
358
Replies
0
Views
593
Replies
6
Views
671
Replies
0
Views
328
Replies
2
Views
826
Replies
4
Views
625
Replies
4
Views
535
Replies
6
Views
530
Replies
11
Views
4K
Replies
0
Views
441
Replies
0
Views
319
Replies
1
Views
368
Replies
0
Views
317
Replies
2
Views
884
Replies
1
Views
403
Replies
3
Views
363
Replies
9
Views
965
Replies
10
Views
689
Replies
0
Views
355
Replies
7
Views
646
Replies
0
Views
536
Replies
2
Views
402
Replies
5
Views
530
Replies
9
Views
759