Any delay you experience is due to the child process, which buffers
its output. Also, tail -f does not react immediately to changes in the
file it's monitoring (e.g. GNU tail waits 1 second between updates by
default).

You could implement tail -f in Java and avoid the issue altogether.

/gordon

--

If you can modify the child code, turn off any System.err and
System.out buffering, and do .flush periodically to send the output
off to the waiting mother task.

To add to the previous responses, many command line programs
will buffer output when they are connected to a pipe, but not
when connected to a terminal or console. This makes it
difficult to run an interactive program through a Java launcher
program that provides the I/O as, for example, an IDE might do.

In UNIX/Linux, you can insert a native program between Java
and the target that connects to the target using a pty, and feeds
the target's output to the Java program as soon as it gets it. The
"wedge" code that is distributed with jGRASP provides that
function (and others) and is free of license restrictions. On
Windows, the situation is more difficult. There is no
"pseudoconsole". You can sort-of build one on NT/XP by
running the target in debug mode and intercepting console
writes, but it is difficult to distinguish input from output, and
you have to give up if there is any "cursor movement". I used
Gordon Chaffee's Windows port of "Expect" as a guide for
building such a program.