ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 24918] - [PATCH] Permit console input to be sent to <java>
Date Mon, 24 Nov 2003 18:15:09 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24918>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24918

[PATCH] Permit console input to be sent to <java>





------- Additional Comments From jglick@netbeans.org  2003-11-24 18:15 -------
Re. pumping more input into the task than it takes - not sure, but it worked for
me at least on Linux to run the process twice from the same Ant target. Feed the
first process some input, it echoes it as it goes, press Ctrl-D, the first
process ends and the second process begins, feed it some input, it gets echoed,
press Ctrl-D, the second process ends and the build completes.

However this test program was designed to accept stdin until it gets EOF, and
react quickly to input relative to interactive typing speed. If there is a
process which takes stdin for a while and then stops (e.g. upon receiving a line
like "exit") and closed stdin and then does some lengthy calculation while you
continue typing, then I suppose some of the input could be sent to the process
where it will not be accepted, which would throw an IOException in StreamPumper.
Not sure how to fix that except by checking the process after every byte is
written to see if the OutputStream is closed. Anyway if the process does not
close stdin but simply stops checking it then there is no way for the
StreamPumper to know whether it is going to want more input or not, so it must
assume that it will and send it.

Realistically, I can't imagine many use cases for interactive process input that
would involve more than one process per Ant run, or non-stdin-driven programs,
so I imagine this is a corner case.

Re. potential for deadlock while read is blocked - not sure what you mean.

Re. <java fork="false"> accepting input (unless -noinput is given) while <java
fork="true"> does not and this being intentional - OK I suppose, though this
still sounds weird. Why (from a user perspective) should forking or not forking
affect whether the <java> task accepts input?

----

Now for the experiment: change the Java code in the test build script to read:

...
public static void main(String[] x) throws Exception {
...
System.err.println("got: " + line);
Thread.sleep(3000);
...

so that the process waits to get further input. Then run

ant -f /tmp/foo.xml nofork-nostdin nofork-nostdin

(using an unpatched Ant here)

and when the 1st process is ready, enter "a" RET, "b" RET, "c" RET, Ctrl-D, "1"
RET, "2" RET, "3" RET, Ctrl-D in quick sequence. I get

nofork-nostdin:
     [echo] nofork=true stdin=false
a
     [java] got: a
b
c
1
2
3
     [java] got: b
     [java] got: c
     [java] got: 1
     [java] got: 2
     [java] got: 3

compile:
     [echo] Ant: Apache Ant version 1.7alpha compiled on November 22 2003
    [javac] Compiling 1 source file to /tmp

nofork-nostdin:
     [echo] nofork=true stdin=false

i.e. all the input was sent to the first process. Then it is waiting again for
the second, which you can still use and finish normally. So basically if you
type ahead, it will go to the process current running, even if you put in a Ctrl-D.

By comparison, using bash if you run

$ echo Running 1; java -cp /tmp TestIn; echo Running 2; java -cp /tmp TestIn

and type the same things, it works almost exactly the same:

Running 1
a
got: a
b
c

1
2
3
got: b
got: c
got: 
got: 1
got: 2
got: 3
Running 2

So if this is a bug, it is a bug which is shared even by the Unix shell -
probably not something to worry about.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message