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 [EMAIL PROTECTED] 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
