Windows start script interprets commas (,) and splits arguments where it should just pass them to the application

[mpollmeier]

Expected behaviour

Commas (,) in arguments should be handed over to the application rather than interpreted by the start script.

Actual behaviour

For the linux start script, that's the case.
The windows starter script interprets the comma and splits it up into separate arguments.

Way to reproduce

mkdir -p project src/main/scala
echo 'sbt.version=1.10.5' > project/build.properties
echo 'addSbtPlugin("com.github.sbt" % "sbt-native-packager" % "1.10.4")' > project/plugins.sbt
echo 'enablePlugins(JavaAppPackaging)' > build.sbt
echo 'object Foo { 
  def main(args: Array[String]) = { 
    println(args.size)
    args.foreach(println) 
  }
}' > Foo.scala
sbt stage

# on linux:
target/universal/stage/bin/native-packager-demo a b,bb c
3
a
b,bb
c

# on windows:
.\target\universal\stage\bin\native-packager-demo.bat a b,bb c
4
a
b
bb
c

Workaround: triple double-quotes

.\target\universal\stage\bin\native-packager-demo.bat a """b,bb""" c
3
a
b,bb
c

Extra context

This is not a windows powershell issue - the below works correctly on both linux and windows:

echo 'class Bar {
  public static void main(String[] args) {
    System.out.println(args.length);
    for (String arg : args) { 
      System.out.println(arg);
    }
  }
}' > Bar.java

java Bar.java a b,bb c
# output on both linux and windows:
3
a
b,bb
c

[mpollmeier]

Looks like shift (or rather %%0!?) might be to blame. Here's a simplified version of the script that shows how shift splits up the args on whitespace as well as comma ,:

@setlocal enabledelayedexpansion
@echo off

call :process_args a b,bb c
@endlocal

exit /B 0

:process_args
  shift
  call set _PARAM1=%%0
  echo PARAM1=%_PARAM1%
  shift
  call set _PARAM1=%%0
  echo PARAM1=%_PARAM1%
  shift
  call set _PARAM1=%%0
  echo PARAM1=%_PARAM1%
  shift
  call set _PARAM1=%%0
  echo PARAM1=%_PARAM1%

output:

PARAM1=a
PARAM1=b
PARAM1=bb
PARAM1=c

[mpollmeier]

Hmm, so according to https://stackoverflow.com/a/8145923 commas are separators for arguments in windows, so this behaviour is actually expected. If we use %~0 instead of %%0 it would at least work if the parameter was quoted ("b,bb"). That change would probably be worthwhile and simplify the workaround (only one quote instead of three). The main issue will remain though, it's the nature of windows batch files.

Let me know if you want to keep this open for discussion, otherwise we can close this issue.

[muuki88]

Hi @mpollmeier

Thanks for the detailed description and follow up of your findings 🙏 ❤️

I can't speak for any windows users as I never had to shipped on windows or coded on windows. I'm happy to merge your suggestion, if you want to provide a PR 😊

If we use %~0 instead of %%0 it would at least work if the parameter was quoted ("b,bb"). That change would probably be worthwhile and simplify the workaround (only one quote instead of three)

[dwickern]

I wish I knew of a better way. Currently the bat script needs to understand how many arguments to consume for every input. For example, this code handles -J-XX:key=value:

sbt-native-packager/src/main/resources/com/typesafe/sbt/packager/archetypes/scripts/bat-template

Lines 159 to 166 in 6b69d6c

	call set _TEST_PARAM=!_TEST_PARAM:~2!
	if not "!_TEST_PARAM:~0,5!" == "-XX:+" if not "!_TEST_PARAM:~0,5!" == "-XX:-" if "!_TEST_PARAM:~0,3!" == "-XX" (
	rem special handling for -J-XX since '=' gets parsed away
	for /F "delims== tokens=1,*" %%G in ("!_TEST_PARAM!") DO (
	call set _TEST_PARAM=!_TEST_PARAM!=%%1
	shift
	)
	)

If you pass -J-XX:MaxGCPauseMillis=500, the script sees
%0 = -J-XX:MaxGCPauseMillis
%1 = 500
and then it concatenates them back together with an =

If you pass -J-XX:+UseG1GC, the script knows there's no equal sign so it only consumes one argument.

For a more extreme example, see how sbt handles -agentlib:jdwp=.... It's not correct in general because -agentlib:jdwp has a variable number of arguments.