DO NOT REPLY [Bug 46203] New: task can lose data

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=46203

           Summary: <input> task can lose data
           Product: Ant
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Core tasks
        AssignedTo: notifications@ant.apache.org
        ReportedBy: sandman@electric-cloud.com


Scenario:

I have an ant file with three input tasks.  When run interactively, they prompt
me, I input whatever values, and all is well.

But now I want to automate running this ant file, so I generate a response file
and feed it into ant as stdin:

ant ... < response.txt

The first input task sucks in the whole response file and the other input tasks
get nothing.  The reason is that DefaultInputHandler.handleInput uses a
BufferedReader on the stdin stream, reads one line (which effectively causes
the buffered reader to read everything it sees), and then the buffered reader
goes out of scope.

Possible solutions:
1. Somehow push back the extra bytes that were read so that the next input task
can read the next line, or
2. Store that BufferedReader somewhere and have the next input task use it
instead of creating a new one, or
3. Don't use a BufferedReader at all; but then you'd lose the ability to do a
readLine.

Pleas for forgiveness:
* This is a problem that one of my customers has, not me, so I don't have the
full context in which they're doing this.  Essentially, they're using my
company's product to automate something that they normally do by hand /
interactively.  That's all I know.
* I'm not an ANT expert or even novice by any stretch of the imagination, so
forgive me if I'm not using the right terminology in this bug report.
* Even if there's a better way to set up an ANT file to handle interactive and
non-interactive use, I don't know if the customer is willing to make dramatic
changes.  This is a bug.
* The current work-around I've given them is to have a Perl script that prints
a line, sleeps, prints the next line, sleeps, etc.  Not the best solution in
the world, but effective for the time being.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 46203] task can lose data

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=46203





--- Comment #1 from Stefan Bodewig <bo...@apache.org>  2008-11-14 03:57:31 PST ---
actually, things are a lot worse - and a lot more difficult to fix.  Throw in
an <exec> task and all bets are off
http://ant.apache.org/faq.html#input-makes-exec-hang

There is a recommended way for reading an input's tasks input from a file and
that is to use a different InputHandler.  Your customer shouldn't use stdin
redirects at all, this is not a supported use-case for input (and thus I could
simply claim it is a bug).

What you should use is a properties file with the answers to your different
input tasks (the keys of that property files are the input's prompts) and a
PropertyFileInputHandler.

I know you said you may not be able to change things on your side, but this is
at least as much a "you are using ant in a way that it doesn't support" as a
bug.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 46203] task can lose data

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=46203





--- Comment #2 from Stefan Bodewig <bo...@apache.org>  2008-11-14 05:47:49 PST ---
I just had a quick look at the code and I'm afraid the problem isn't fixable.

While we may be able to remove the BufferedReader and implement out our
end-of-line detection, we really really want the Java classlib to do the
byte-to-character conversion for us.

InputStreamReader performs buffering itself, the javadocs state it might read
more bytes than are strictly required for a given read(), so even without the
BufferedReader we could (and probably) would end up reading too far.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

DO NOT REPLY [Bug 46203] task can lose data

[bu...@apache.org]

https://issues.apache.org/bugzilla/show_bug.cgi?id=46203


J.M. (Martijn) Kruithof <jk...@apache.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX




--- Comment #3 from J.M. (Martijn) Kruithof <jk...@apache.org>  2009-02-07 11:12:44 PST ---
I'd suggest to do use one of the following methods:

1) Use an input file per exec task
2) Use inputstring in combination with properties

As there may be tasks, unknown to us, using standard in, there is nothing 
we can do to fix this issue. (If this were not the case we could have wrapped
standard in somehow and used that everywhere instead, this does not seem to be
a viable path.)


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.