Add the possibility to run scala scripts

[plafue]

This is a very naive implementation in order to support running scala scripts, even in folders that do not contain sbt projects. Saving the following snippet

/***

libraryDependencies += "com.github.lalyos" % "jfiglet" % "0.0.7"

*/

import com.github.lalyos.jfiglet.FigletFont;
val msg = if (args.size > 0) args.mkString(" ") else ""
val asciiArt = FigletFont.convertOneLine(s"hello $msg!");
System.out.println(asciiArt);

and running sbt -script snippet.scala sbt extra yields

[info] Loading global plugins from /home/user/.sbt/0.13/plugins
[info] Set current project to cc88a3ff57276e4d8968 (in build file:/home/user/.sbt/boot/cc88a3ff57276e4d8968/)
 _            _  _               _      _                 _                 _ 
| |__    ___ | || |  ___    ___ | |__  | |_    ___ __  __| |_  _ __   __ _ | |
| '_ \  / _ \| || | / _ \  / __|| '_ \ | __|  / _ \\ \/ /| __|| '__| / _` || |
| | | ||  __/| || || (_) | \__ \| |_) || |_  |  __/ >  < | |_ | |   | (_| ||_|
|_| |_| \___||_||_| \___/  |___/|_.__/  \__|  \___|/_/\_\ \__||_|    \__,_|(_)

thus demonstrating that residual_args are also properly passed to the script.

I'm not sure if this PR would be affected by the bug described in #122.
Any feedback would be very much appreciated.

[dwijnand]

The change looks good. I wonder with the precedent of -sbt-create this would be better called -sbt-create.

Btw this is what #122 looks like, using this change:

$ sbt -v -script snippet.scala sbt extra
[addJava] arg = '-Dsbt.main.class=sbt.ScriptMain'
[residual] arg = 'sbt'
[residual] arg = 'extra'
No extra sbt options have been defined
Detected sbt version 0.13.11
Using default jvm options
Detected Java version: 1.8.0_74
# Executing command line:
/Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home/bin/java
-Xms512m
-Xmx1536m
-Xss2m
-XX:ReservedCodeCacheSize=256m
-XX:+TieredCompilation
-XX:+CMSClassUnloadingEnabled
-XX:+UseConcMarkSweepGC
-Dsbt.main.class=sbt.ScriptMain
-jar
/Users/dnw/.sbt/launchers/0.13.11/sbt-launch.jar
warn
"set javaHome in ThisBuild := scala.Some(file("/Library/Java/JavaVirtualMachines/jdk1.8.0_74.jdk/Contents/Home"))"
info
snippet.scala
sbt
extra

[info] Loading global plugins from /Users/dnw/.dotfiles/.sbt/0.13/plugins
java.io.FileNotFoundException: /s/warn (No such file or directory)
    at java.io.FileInputStream.open0(Native Method)
    at java.io.FileInputStream.open(FileInputStream.java:195)
    at java.io.FileInputStream.<init>(FileInputStream.java:138)
    at sbt.Using$$anonfun$fileReader$1.apply(Using.scala:79)
    at sbt.Using$$anonfun$fileReader$1.apply(Using.scala:79)
    at sbt.Using$$anon$2.openImpl(Using.scala:65)
    at sbt.OpenFile$class.open(Using.scala:43)
    at sbt.Using$$anon$2.open(Using.scala:64)
    at sbt.Using$$anon$2.open(Using.scala:64)
    at sbt.Using.apply(Using.scala:23)
    at sbt.IO$.readLines(IO.scala:741)
    at sbt.Script$.blocks(Script.scala:43)
    at sbt.Script$$anonfun$command$1.apply(Script.scala:26)
    at sbt.Script$$anonfun$command$1.apply(Script.scala:14)
    at sbt.Command$$anonfun$command$1$$anonfun$apply$1.apply(Command.scala:30)
    at sbt.Command$$anonfun$command$1$$anonfun$apply$1.apply(Command.scala:30)
    at sbt.Command$.process(Command.scala:93)
    at sbt.MainLoop$$anonfun$1$$anonfun$apply$1.apply(MainLoop.scala:96)
    at sbt.MainLoop$$anonfun$1$$anonfun$apply$1.apply(MainLoop.scala:96)
    at sbt.State$$anon$1.process(State.scala:184)
    at sbt.MainLoop$$anonfun$1.apply(MainLoop.scala:96)
    at sbt.MainLoop$$anonfun$1.apply(MainLoop.scala:96)
    at sbt.ErrorHandling$.wideConvert(ErrorHandling.scala:17)
    at sbt.MainLoop$.next(MainLoop.scala:96)
    at sbt.MainLoop$.run(MainLoop.scala:89)
    at sbt.MainLoop$$anonfun$runWithNewLog$1.apply(MainLoop.scala:68)
    at sbt.MainLoop$$anonfun$runWithNewLog$1.apply(MainLoop.scala:63)
    at sbt.Using.apply(Using.scala:24)
    at sbt.MainLoop$.runWithNewLog(MainLoop.scala:63)
    at sbt.MainLoop$.runAndClearLast(MainLoop.scala:46)
    at sbt.MainLoop$.runLoggedLoop(MainLoop.scala:30)
    at sbt.MainLoop$.runLogged(MainLoop.scala:22)
    at sbt.StandardMain$.runManaged(Main.scala:54)
    at sbt.ScriptMain.run(Main.scala:37)
    at xsbt.boot.Launch$$anonfun$run$1.apply(Launch.scala:109)
    at xsbt.boot.Launch$.withContextLoader(Launch.scala:128)
    at xsbt.boot.Launch$.run(Launch.scala:109)
    at xsbt.boot.Launch$$anonfun$apply$1.apply(Launch.scala:35)
    at xsbt.boot.Launch$.launch(Launch.scala:117)
    at xsbt.boot.Launch$.apply(Launch.scala:18)
    at xsbt.boot.Boot$.runImpl(Boot.scala:41)
    at xsbt.boot.Boot$.main(Boot.scala:17)
    at xsbt.boot.Boot.main(Boot.scala)
[error] java.io.FileNotFoundException: /s/warn (No such file or directory)
[error] Use 'last' for the full log.

[dwijnand]

The above is with a JAVA_HOME home, which I normally don't have, favouring jenv's way instead.

I'm assuming you don't have one set either.

[plafue]

That's correct, JAVA_HOME is not set in my environment.

Just for clarification: in your comment you mentioned -sbt-create twice. Did you mean -sbt-script the second time around? I'm perfectly fine renaming that.

[dwijnand]

Yep, I meant -sbt-script.

[plafue]

I was thinking about renaming the new parameter to -sbt-script... it seems like -sbt-* parameters are rather runtime configuration, and the most similar in behaviour would be -prompt, which does not have the -sbt prefix.

Also it may be a bit misleading, as -sbt-script expects a scala script - a future reader may think that the value to this parameter is a 'sbt script' (analog to -sbt-launch-dir and others).

[dwijnand]

I could make more arguments for -sbt-script, but I actually think I'm happy with -script.

[plafue-soundcloud]

Cool, thanks!

[paulp]

I was going to cast a vote against this but I guess I should move faster. I expect this to create a maintenance burden. I also hate -sbt-create as an option name and would like it shortened to one letter. But my focus is elsewhere so I defer to dale.

[vn971]

Does anyone run scala scripts using shebang? Once configured, it looks like:

#!/usr/bin/env scalas
println("my scala code here")

I'm not able to use the current sbt script and any scalas wrappers on it to launch the script. I think it worked in the past, like 1 year ago, but it surely doesn't now for me.

The old script I used is: sbt -Dsbt.main.class=sbt.ScriptMain -sbt-create -Dsbt.boot.directory="$HOME"/.sbt/boot "$@"

But it throws the following error now:
[error] java.io.FileNotFoundException: /home/myname/warn (No such file or directory)

[dwijnand]

@vn971 That's because of #122

[vn971]

Yes, indeed it did break a year ago. This commit broke scalas functionality of sbt: d2f93aa
I'll try to fix it on my own now. Will either PR or ask for help.

[vn971]

@dwijnand BTW, you are the author of that commit if I got things right.:)

[vn971]

OK, I fixed it: https://github.com/paulp/sbt-extras/pull/146/files

Offtopic: does anyone know why sbt is launched without the errexit, errtrace and nounset directives?
Is it a historical mistake? The unbounded variable I fixed would not have passed the nounset check. And at the same time, this is a very hard-to-spot bug. Who would expect a bug in this simple code?...
if [[ -e "$JAVA_HOME/bin/java" ]]; then

[vn971]

UPD: I think only fixed one of the bugs present now.

While fixing this unbound variable was necessary, SBT got broken by a different cause. It broke because of the addSbt warn directive. As far as I understand it, addSbt bash function simply does not work. If you never invoke it (most usages of SBT), you will not see the bug.

The "fix" I made accidentally removes a usage of this addSbt bash function. And only for those who had not set $JAVA_HOME... The rest will still hit the faulty addSbt.

That's is my impression while working with the code, anyway. I may be wrong. Please correct me if so.

[dwijnand]

It's more that sbt.ScriptMain doesn't handle extra sbt commands like the default runner: sbt.xMain.

[vn971]

@dwijnand Probably so. I can't make sbt.ScriptMain work with the old "additional sbt commands". Not even by using the simplest java -D*** -jar sbt-launcher.jar.

That means we just can't pass "additional sbt commands" to the latest script launcher.

So, we should either revert the tricky sbt.ScriptMain behavior or stop passing any sbt commands. (Remove all usages of addSbt bash function.) The simplest solution is to remove usages of course, they're strange anyway.

Who would be competent or initiative enough to make that decision?...