exec() and my stupidity

[Raghu Devatha]

I just wanted to share my stupidity and how I used up all the disk space, about 90 GB with a couple of lines of code.

All I wanted to do was to list out all the files in a directory (including the sub-directory) containing a set of string and save the information in a file. I thought find would help, I tested that as well....

find . -exec grep -i "TEXT_TO_FIND" '{}' \; -print >TEXT_TO_FIND.txt

However, I need to pick up the string to search dynamically and build the command string dynamically, after figuring out the right way of building the command string , I ran my program. I thought exec() would wait
for a signal from the Operating system that the task has finished. I think it does not. Even if it did, my program will never complete because it would also search in the files which I have been creating by redirecting,
the output and thus grep was running indefinitely until all the disk space was utilized.

I just want to confirm that Runtime.getRuntime().exec(cmd); does not wait for any signal from OS.

[Ulf Dittmer]

It sure does. Be sure to read and follow all the advice in this article.

[Campbell Ritchie]

Moving thread as Runtime.exec() is too difficult for “beginning”
By the way: the ProcessBuilder class makes Runtime.exec() slightly easier to use. But only slightly. You still need to “drain” both Streams.

[Winston Gutkowski]

Raghu Devatha wrote:I just want to confirm that Runtime.getRuntime().exec(cmd); does not wait for any signal from OS.

Seems to me that you've leapt to an implementation rather too quickly. I'm pretty sure the File (java.io.File) class, along with Matcher (java.util.regex.Matcher), has everything you need to to do what you want; and it's likely to be far more dynamic than a Runtime.exec()-based solution.

If you're writing a script, find's your man (although it only exists on Unix/Linux; unless you're into Cygwin installations). If you're writing Java code, use the classes it provides.

Winston