Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

task created by fullRunInputTask doesn't capture sys.exit #831

Closed
eed3si9n opened this issue Jul 28, 2013 · 8 comments
Closed

task created by fullRunInputTask doesn't capture sys.exit #831

eed3si9n opened this issue Jul 28, 2013 · 8 comments
Assignees
Labels
Bug
Milestone

Comments

@eed3si9n
Copy link
Member

@eed3si9n eed3si9n commented Jul 28, 2013

steps

  1. write a program that calls sys.exit when you pass in "--help" to argument. (scopt does this)
  2. in build.sbt, define fullRunInputTask(InputKey[Unit]("custom_run"), Runtime, "Main")
  3. from the shell, call custom_run --help.

problem

the program runs, and upon sys.exit sbt itself shuts down.

expectation

the program shuts down, and returns to sbt shell as run task does.

note

Mark wrote:

[trapExit] will fix the issue. However, the reason it isn't on by default is that it can only handle one run at a time (it is a SecurityManager hack to begin with). This issue will be to try to handle independent executions simultaneously.

@ceilican
Copy link

@ceilican ceilican commented Jul 28, 2013

More generally, SBT seems to treat run tasks created with fullRunInputTask quite differently from the way it treats the default run task.

The issue described above is just one consequence.

Another consequence is this: if an exception is thrown within a program executed via run, SBT shows the full exception message. On the other hand, if the program is executed via a custom-run, SBT hides the exception message and requires the user to type last *:custom-run to see it.

I know nothing about the internals of SBT and the technical difficulties involved. But judging purely from a user perspective, it would be nice if SBT could provide a uniform treatment of default and custom run tasks.

@ceilican
Copy link

@ceilican ceilican commented Jul 28, 2013

Apparently, SBT executes default run tasks in a separate JVM (and thus is not terminated when a default run task calls sys.exit), but custom run tasks in the same JVM (and thus is terminated when the custom run task calls sys.exit).

@harrah
Copy link
Member

@harrah harrah commented Jul 29, 2013

Both the default and custom run tasks are configured by fork, which is false by default. Saying fork in run will configure only the default run. The amount of a trace shown is configured by traceLevel, which is configured for run by default using traceLevel in run := 0. A custom run-like task can be configured similarly. fullRunInputTask does not control that. Rather, it is more like a property of the key.

@ceilican
Copy link

@ceilican ceilican commented Jul 30, 2013

Thanks for the explanation, Mark!

I thought fullRunInputTask would define a custom_run task that behaves exactly like run (w.r.t. fork, traceLevel, resilience to sys.exit calls, and so on...).

Since it doesn't, could you tell me the simplest way to define (in build.sbt) a custom_run task that behaves exactly like run?

@harrah
Copy link
Member

@harrah harrah commented Jul 31, 2013

Configure the revelant settings in customRun:

trapExit in customRun := true

fork in customRun := true

traceLevel in customRun := 0

@eed3si9n I forgot about trapExit. That will fix the issue. However, the reason it isn't on by default is that it can only handle one run at a time (it is a SecurityManager hack to begin with). This issue will be to try to handle independent executions simultaneously.

@ghost ghost assigned harrah Jul 31, 2013
@ceilican
Copy link

@ceilican ceilican commented Jul 31, 2013

So now I have something like this in my "build.sbt":

fullRunInputTask(InputKey[Unit]("customRun"), Runtime, "Main")

trapExit in customRun := true

fork in customRun := true

traceLevel in customRun := 0

And SBT complains:

/Users/Bruno/Dropbox/Code/Skeptik/build.sbt:111: error: not found: value customRun
trapExit in customRun := true
            ^
/Users/Bruno/Dropbox/Code/Skeptik/build.sbt:111: error: reassignment to val
trapExit in customRun := true
                     ^

I understand why this happens. My question is: is there a way to achieve what I want having only a "build.sbt" file? Or will I need to write a "Build.scala" file, in order to use the full power of the Scala language (even if in this case I just need to know the key object that was created by fullRunInputTask)?

@harrah
Copy link
Member

@harrah harrah commented Jul 31, 2013

0.13 allows vals in the .sbt file. Before that, you can use a block and return a Seq[Setting[_]] in the expression:

{
  val customRun = InputKey[Unit]("customRun")
  Seq(
    trapExit in customRun := true,
    ...
  )
}

(EDIT: forgot the {} the first time)

@ceilican
Copy link

@ceilican ceilican commented Aug 1, 2013

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.