+1 on this, using Gradle 1.0-milestone-3.

If running under java 6 you have access to System.console() and you can kind of get a readable prompt for your user input. Under java < 6 this seems very tricky indeed.

To illustrate, here is a snippet of code with a task where I'm trying to read some user input from the console:

task getinput { 
  println "------------------"
  def userInput = 'notset'
  def prompt = "Provide value: "

  if (System.metaClass.respondsTo(System, "console") && System.console()) {
    userInput = System.console().readLine("\n$prompt")
  } else {
    logger.error("")
    logger.error ("\n$prompt")
    println ""
    new Thread({
      Thread.sleep(500)
      logger.error("")
      println ""
    }).start()
    userInput = System.in.newReader().readLine()
  }

  println "VALUE PROVIDED: $userInput"
  println "------------------"
}

The code results in the following under java 6:

$ gradle getinput
------------------
> Loading
Provide value: myvalue
VALUE PROVIDED: myvalue
------------------
:getinput UP-TO-DATE

BUILD SUCCESSFUL

Total time: 6.234 secs

and the following under java < 6:

$ gradle getinput
------------------


Provide value: 



> Loadingmyvalue
VALUE PROVIDED: myvalue
------------------
:getinput UP-TO-DATE

BUILD SUCCESSFUL

Total time: 5.946 secs

As can be seen from the example output, this is ugly (we still get the "> Loading" string) but works under java 6. Under java versions < 6 the user interface becomes very confusing and close to unusable. Imagine shipping this prompt to a couple of hundred offshore developers...

A few notes on this:

• In the java 6 clause, newline in the readLine("\n$prompt") string forces the prompt to a different line than the "> Loading" string.
• In the java < 6 clause, we can see that I have gone to some extreme lengths to try to force the prompt onto the next line...even using a separate thread with a delay. No luck there. Even after the thread output the "> Loading" string just gets moved a few lines down and still ends up prefixing the user input.
• I have tried and tried again to convince the logging level of gradle to temporarily lower itself to quiet which would make logging behave the way it does when running using "gradle -q". I haven't been able to find a way to do this.

Some might argue that user input like this is a non essential feature for a build system. I would have to strongly disagree on this. User interface design is important (look at early versions of git and what it did to usability and adoption) and the console is what we have to work with. As an example: asking for say a jboss installation location on the building machine so that we can automate instance launch seems like something we really should be able to do.

Another comment on this. If running with "gradle --daemon" the System.console() call will always return null. This is per design of the java console class.

As System.console() was the only somewhat acceptable solution for getting hold of user input and as the daemon mode will be default going forward this makes the severity of this issue higher. This essentially means that the work around for getting hold of user input despite the intrusive progress logging is going away in future releases of gradle.

This issue seems related to GRADLE-1168.

Hmm. This has been open for some time. I'm trying to write a task that starts up `groovysh` with the projects runtime classpath. However, the status message keeps getting in the way and messes up the input as well...

I also want to start groovysh, and it gets in my way.

TERM=dumb gradle <task>

works, but I need a non-dumb terminal for a pretty groovysh.

I'd love to see this issue resolved. As a workaround, you can use:

gradle --console plain run

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

This is still a problem.

+1, this is still an active request

We are currently working on improved console output. You can find the spec here. In the course of this work we'll also address how standard input is captured. I am going to mark the issue as "Won't fix". Look out for improved console output in the upcoming releases of Gradle.