TCC Quotes needed for Arguments containing '='?

[greyfairer]

Hi all,

I'm having a weird issue in TCC. I tried commands including equals signs, like e.g:

mvn -Denv=local​

This calls mvn.bat (Apache Maven), which launches a java process, using:

set MAVEN_CMD_LINE_ARGS=%*
"%JAVA_HOME%\bin\java.exe" ... %MAVEN_CMD_LINE_ARGS%
​

In the java process, the argument '-Denv=local' seems to be split, since it complains: 'Unknown lifecycle phase "local"'.

It works if I quote the argument:

mvn "-Denv=local"
​

This is quite annoying, and incompatible with e.g. bash or CMD.
Is there a workaround for this?

Grts, Geert.

PS: This still occurs in TC 16.

 

[Steve Fabian]

Sorry, but it is CMD that changed the rules years ago, the equal sign (=) became an argument separator. Lots of complaints back then, but we have come accustomed to the CMD style.

 

[Charles Dye]

On a related note, I tried checking the current behavior with a batch file:

@echo off
echo %%* = '%*'
echo %%1 = '%1'
echo %%2 = '%2'
echo %%3 = '%3'
echo %%4 = '%4'
echo %%5 = '%5'

The %1, %2, %3, etc. all worked as expected. But for some reason, the second line always displays a '*'. It seems that the trailing apostrophe prevents the expansion of the %*. Am I missing something obvious?

(Adding) This is not new behavior, by the way. It's unchanged since at least v13.

 

[greyfairer]

Sorry, but it is CMD that changed the rules years ago, the equal sign (=) became an argument separator. Lots of complaints back then, but we have come accustomed to the CMD style.

It works as expected in CMD (Win7): -Denv=dev is passed as a single argument to the java process.

Same holds for ',', eg 'mvn -pl alpha,beta' -> beta is interpreted as a separate argument in TCC, not in CMD.

Maybe it's just the %* expansion (used inside mvn.bat)?

 

[Steve Fabian]

Than again Microsoft may have changed back to the older syntax (at least in this instance). Backward compatibility is not only not high on Microsoft's priorities, it appears to be anathema. I do not use CMD, wouldn't have known years back that the change was made for CMD compatibility if not for the complaints.

 

[Charles Dye]

It works as expected in CMD (Win7): -Denv=dev is passed as a single argument to the java process.

Same holds for ',', eg 'mvn -pl alpha,beta' -> beta is interpreted as a separate argument in TCC, not in CMD.

Maybe it's just the %* expansion (used inside mvn.bat)?

So far as I can tell, CMD.EXE and TCC behave the same way. It might be helpful to add e.g.

set MAVEN_CMD_LINE_ARGS
pause

to your batch file after the variable is set, so you can check the value that the variable receives.

 

[vefatica]

What about the semicolon? TCC doesn't use it as an arg delimiter; CMD does.

v:\> type echoargs.bat
@echo off
echo %*
echo %1
echo %2
echo %3
echo %4

v:\> ver & echoargs.bat a=b;c

TCC  16.00.36  Windows 7 [Version 6.1.7601]
a=b;c
a
b;c
ECHO is OFF
ECHO is OFF

v:\> ver & echoargs.bat a=b;c

Microsoft Windows [Version 6.1.7601]
a=b;c
a
b
c
ECHO is off.

 

[Charles Dye]

What about the semicolon? TCC doesn't use it as an arg delimiter; CMD does.

I never knew that. For include lists, perhaps?

 

[vefatica]

I never knew that. For include lists, perhaps?

Is there anything special about include lists? There are many other instances where CMD compatibility limits TCC functionality ... but we're stuck with them anyway.

 

[Steve Fabian]

I voted for CMD incompatibility long ago unless "Duplicate CMD bugs" is checked, when a quite different syntax would take over... Every year it will be more difficult to have two different syntaxes merged. The more features TCC the more likely CMD will come up with a conflicting syntax.

 

[rconn]

What about the semicolon? TCC doesn't use it as an arg delimiter; CMD does.

I'm not sure what you're arguing for here -- you want to eliminate include lists so you can use a semicolon as a batch delimiter?

 

[vefatica]

I'm not sure what you're arguing for here -- you want to eliminate include lists so you can use a semicolon as a batch delimiter?

It was just a comment on "CMD compatibility" ... a rather ill-defined notion that I'd be glad to do without.