Question

After using batch files for many years I was surprised to discover that the equals sign ‘=’ is considered an argument separator.

Given this test script:

echo arg1: %1
echo arg2: %2
echo arg3: %3

and an invocation:

test.bat a=b c

the output is:

arg1: a
arg2: b
arg3: c

Why is that and how can it be avoided? I don’t want the user of the script to account for this quirk and quote “a=b”, which is counter-intuitive.

This batch script was run on Windows 7.

===== EDIT =====

A little more background: I encountered this problem when writing a bat file to start a Java application. I wanted to consume some args in the bat file and then pass the rest to the java application. So my first attempt was to do shift and then rebuild the args list (since %* is not affected by shift). It looked something like this, and that’s when I discovered the issue:

rem Rebuild the args, %* does not work after shift
:args
if not "%1" == "" (
  set ARGS=!ARGS! %1
  shift
  goto args
)

The next step was to not use shift anymore, but rather implement shift by hand by removing one character at a time from %* until a space is encountered:

rem Remove the 1st arg if it was the profile
set ARGS=%*
if not "%FIRST_ARG%" == "%KNOA_PROFILE%" goto remove_first_done
:remove_first
if not defined ARGS goto remove_first_done
if "%ARGS:~0,1%" == " " goto remove_first_done
set ARGS=%ARGS:~1%
goto remove_first
:remove_first_done

But this is ugly and might still fail in some cases I haven’t considered. So finally I decided to write a Java program to deal with the argument parsing! In my case this is fine, since I am launching a server and the penalty of an extra java invocation is minimal. It’s mind-boggling what you end up doing sometimes.

You might wonder why didn’t I take care of the args in the Java application itself? The answer is that I want to be able to pass JVM options like -Xmx which must be processed before invoking java.

Answer 1

I’m guessing it does this so that /param=data is the same as /param data

I don’t know any tricks to fix that stupid (probably by design) parsing issue but I was able to come up with a super ugly workaround:

@echo off
setlocal ENABLEEXTENSIONS
set param=1
:fixnextparam
set p=
((echo "%~1"|find " ")>nul)||(
    call :fixparam %param% "%~1" "%~2" %* 2>nul
)
if "%p%"=="" (set "p%param%=%1") else shift
shift&set /A param=%param% + 1
if not "%~1"=="" goto fixnextparam

echo.1=%p1%
echo.2=%p2%
echo.3=%p3%
echo.4=%p4%
echo.5=%p5%
goto:EOF


:fixparam
set p%1=
for /F "tokens=4" %%A in ("%*") do (
    if "%%~A"=="%~2=%~3" set p=!&set "p%1=%%A"
)
goto:EOF

When I execute test.cmd foo=bar baz "fizz buzz" w00t I get:

1=foo=bar
2=baz
3="fizz buzz"
4=w00t
5=

The problem with this is of course that you cannot do %~dp1 style variable expansion.
It is not possible to do call :mylabel %* and then use %1 either because call :batchlabel has the same parameter parsing problem!

If you really need %~dp1 handling you could use the WSH/batch hybrid hack:

@if (1==1) @if(1==0) @ELSE
@echo off
@SETLOCAL ENABLEEXTENSIONS
if "%SPECIALPARSE%"=="*%~f0" (
    echo.1=%~1
    echo.2=%~2
    echo.3=%~3
    echo.4=%~4
    echo.5=%~5
) else (
    set "SPECIALPARSE=*%~f0"
    cscript //E:JScript //nologo "%~f0" %*
)
@goto :EOF
@end @ELSE
w=WScript,wa=w.Arguments,al=wa.length,Sh=w.CreateObject("WScript.Shell"),p="";
for(i=0;i<al;++i)p+="\""+wa.Item(i)+"\" ";
function PipeStream(i,o){for(;!i.AtEndOfStream;)o.Write(i.Read(1))}
function Exec(cmd,e){
    try{
        e=Sh.Exec(cmd);
        while(e.Status==0){
            w.Sleep(99);
            PipeStream(e.StdOut,w.StdOut);
            PipeStream(e.StdErr,w.StdErr);
        }
        return e.ExitCode;
    }catch(e){return e.number;}
}
w.Quit(Exec("\""+WScript.ScriptFullName+"\" "+p));
@end