[GRADLE-1147] if using stdin status message pollutes the input line Created: 10/Sep/10  Updated: 02/Feb/17  Resolved: 02/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 0.9
Fix Version/s: None

Type: Bug
Reporter: René Gröschke (Inactive) Assignee: Unassigned
Resolution: Won't Fix Votes: 16


While waiting for input from stdin, the input line is polluted by a status message (">Loading" in configuration phase or ">Building" in execution phase). The status message should be removed while waiting for input from stdin.

Comment by Matias Bjarland [ 22/Jun/11 ]

+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:

Trying to read value from 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 ("\n$prompt")
    println ""
    new Thread({
      println ""
    userInput = System.in.newReader().readLine()

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

The code results in the following under java 6:

execution under java 6
$ gradle getinput
> Loading
Provide value: myvalue
:getinput UP-TO-DATE


Total time: 6.234 secs

and the following under java < 6:

execution under java version < 6
$ gradle getinput

Provide value: 

> Loadingmyvalue
:getinput UP-TO-DATE


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.

Comment by Matias Bjarland [ 25/Jun/11 ]

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.

Comment by Matias Bjarland [ 25/Jun/11 ]

This issue seems related to GRADLE-1168.

Comment by Matt Hauck [ 06/Sep/13 ]

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...

Comment by Thibault Kruse [ 20/May/14 ]

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.

Comment by Chris Jones [ 25/Mar/15 ]

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

gradle --console plain run
Comment by Benjamin Muschko [ 15/Nov/16 ]

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!

Comment by Joern Huxhorn [ 15/Nov/16 ]

This is still a problem.

Comment by Matias Bjarland [ 30/Nov/16 ]

+1, this is still an active request

Comment by Benjamin Muschko [ 02/Feb/17 ]

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.

Generated at Wed Jun 30 11:48:08 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.