You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
mpollmeier
changed the title
Windows start script interprets commas (,) and splits arguments, where it should just leave them alone
Windows start script interprets commas (,) and splits arguments where it should just pass them to the application
Nov 20, 2024
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%
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.
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
Workaround: triple double-quotes
Extra context
This is not a windows powershell issue - the below works correctly on both linux and windows:
The text was updated successfully, but these errors were encountered: