Scripting: access to command line arguments

[SethTisue]

the docs say that a hello world script is desugared to:

object hello {
  val message = "Hello from Scala script"
  println(message)

  def main(args: Array[String]): Unit = ()
}

this leaves me unable to reference args

I don't see any information about this on the doc page I linked above

(context: I was hoping I could replace the combination of https://github.com/scala/community-build/blob/2.13.x/advance and https://github.com/scala/community-build/blob/2.13.x/scripts/Advance.scala with a single .sc file, but this is blocking me)

[lrytz]

Not sure about .sc files, but it works with main methods like:

➜ cat A.scala
@main def f(s: String) = println(s"Hello $s")
➜ scala-cli A.scala -- World
Hello World

[SethTisue]

fwiw, Ammonite also requires defining a @main method if you want access to args, https://ammonite.io/#ScriptArguments

@lrytz reports that defining a @main only works if the extension on the file is .scala as opposed to .sc. sorting that out seems like a design question.

my expectation that an explicit main method shouldn't be necessary comes from three places:

• typical scripting languages like bash, Python, Perl

• Scala 2's own script running support, which gives direct access to args:

% echo 'args.foreach(println)' >! S.scala; scala S.scala foo bar
foo
bar

• sbt's ScriptMain support, which is what I was using before for my scripts (since it allows adding dependencies, unlike Scala's own scripting support)

[SethTisue]

and it turns out I'm not actually able to use .scala + @main as a workaround, because then dependencies don't work

I have:

#!/usr/bin/env scala-cli --scala-version 3.1.0-RC2                                                                      

import $dep.`org.scala-lang.modules:scala-parallel-collections_3:1.0.3`
import scala.collection.parallel.CollectionConverters._  // for .par     

but I get:

[error] ./advance.scala:9:8: value parallel is not a member of collection
[error]        ^^^^^^^^^^^^^^^^^^^^^^^^^^
[error] ./advance.scala:30:12: Stable identifier required, but <error value parallel is not a member of collection>#CollectionConverters.scala.
[error]   sys
[error] .process.None found
[error]            ^^^^^
Error compiling project (Scala 3.1.0-RC2, JVM)
Compilation failed

[SethTisue]

@tpasternak I'm having trouble combining this with also passing flags to scala-cli

for example, suppose I want to pass --scala-version 3.1.0

I tried:

#!/usr/bin/env scala-cli --scala-version 3.1.0                                                                          

println(args.size)
println(args.headOption)

and it aaaaaaalmost works right. I can do:

% ./foo.sc    
0
None

and I can do:

% ./foo.sc -- a b c
3
Some(a)

but note that I had to supply the extra -- to make it work. If don't supply that, the result is:

% ./foo.sc a b c   
a: not found
b: not found
c: not found

happy to open a new ticket on this if you'd prefer.

[tpasternak]

Thank you @SethTisue , you're right, I'm reopening the issue

[romanowski]

@SethTisue We are thinking about how to improve the situation and to be honest I cannot see how we can get rid of -- from she-bangs without some strange heuristics that would cause harm in other areas (mainly because it is quite hard to detect reliably if the application is running from she-bang or using scala-cli directly).

Any ideas on how to improve the situation? I do not see any other option than just updating documentation.

[SethTisue]

I haven't thought about this deeply, but I'll throw a couple of questions out there anyway:

would it resolve the ambiguity if we required script authors to include -- in their shebang lines, like this?

#!/usr/bin/env scala-cli --scala-version 3.1.0 --

to make it unambiguous that any arguments passed to the script itself would be interpreted as arguments to the script rather than as arguments to scala-cli itself.

because it is quite hard to detect reliably if the application is running from she-bang or using scala-cli directly

would it help to add a top-level command, called shebang or script or something?

#!/usr/bin/env scala-cli script

[tpasternak]

would it resolve the ambiguity if we required script authors to include -- in their shebang lines, like this?

#!/usr/bin/env scala-cli --scala-version 3.1.0 --

This is not so easy. If you execute ./script.sc arg1 arg2, the result command will be /usr/bin/env scala-cli --scala-version 3.1.0 -- ./script.sc arg1 arg2. This means the ./script.sc will be passed down to the program. Of course we could treat the first argument after the -- specially, but then it would break non-shebang executions. Basically bash and python have it for free, because they accept interpreter arguments before the inputs and program arguments after the inputs. In scala-cli we support multiple inputs (should we?), so we cannot drop -- and take whatever comes after the input file.

would it help to add a top-level command, called shebang or script or something?

#!/usr/bin/env scala-cli script

I did something like this here #410. It's quite dirty, as cheats the caseapp library, but it works

[SethTisue]

I did something like this here #410

offhand, looks fine to me. it's still fairly early days for this project, so I'll be content with anything that gets me unstuck, and that PR looks like it will.

[tpasternak]

scala-cli shebang command added in #410

It will be available in the upcoming release

[tpasternak]

Ok, scala-cli 0.0.9 is out. Your case will work if you use scala-cli shebang. Closing this now, please reopen again if there are any problems still

[SethTisue]

tried it out but was blocked by #451

[SethTisue]

(#451 remains an unreproducible mystery, but:)

yay, this is now working for me for the community build scripts: scala/community-build#1518

👏

[tpasternak]

Thank you @SethTisue !